Commit graph

311 commits

Author SHA1 Message Date
Marcel Holtmann
1a097181ee Bluetooth: Fix Kconfig issue with RFKILL integration
Since the re-write of the RFKILL subsystem it is no longer good to just
select RFKILL, but it is important to add a proper depends on rule.

Based on a report by Alexander Beregalov <a.beregalov@gmail.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-06-14 15:30:51 +02:00
David S. Miller
bb400801c2 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-next-2.6 2009-06-11 05:47:43 -07:00
Marcel Holtmann
611b30f74b Bluetooth: Add native RFKILL soft-switch support for all devices
With the re-write of the RFKILL subsystem it is now possible to easily
integrate RFKILL soft-switch support into the Bluetooth subsystem. All
Bluetooth devices will now get automatically RFKILL support.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-06-08 14:50:01 +02:00
Marcel Holtmann
b4324b5dc5 Bluetooth: Remove pointless endian conversion helpers
The Bluetooth source uses some endian conversion helpers, that in the end
translate to kernel standard routines. So remove this obfuscation since it
is fully pointless.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-06-08 14:50:01 +02:00
Marcel Holtmann
47ec1dcd69 Bluetooth: Add basic constants for L2CAP ERTM support and use them
This adds the basic constants required to add support for L2CAP Enhanced
Retransmission feature.

Based on a patch from Nathan Holstein <nathan@lampreynetworks.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-06-08 14:50:00 +02:00
Gustavo F. Padovan
af05b30bcb Bluetooth: Fix errors and warnings in L2CAP reported by checkpatch.pl
This patch fixes the errors without changing the l2cap.o binary:

 text    data     bss     dec     hex filename
18059     568       0   18627    48c3 l2cap.o.after
18059     568       0   18627    48c3 l2cap.o.before

Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-06-08 14:50:00 +02:00
Marcel Holtmann
44d0e48e8a Bluetooth: Remove unnecessary variable initialization
The initial value of err is not used until it is set to -ENOMEM. So just
remove the initialization completely.

Based on a patch from Gustavo F. Padovan <gustavo@las.ic.unicamp.br>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-06-08 14:50:00 +02:00
Gustavo F. Padovan
589d274648 Bluetooth: Use macro for L2CAP hint mask on receiving config request
Using the L2CAP_CONF_HINT macro is easier to understand than using a
hardcoded 0x80 value.

Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-06-08 14:50:00 +02:00
Gustavo F. Padovan
8db4dc46dc Bluetooth: Use macros for L2CAP channel identifiers
Use macros instead of hardcoded numbers to make the L2CAP source code
more readable.

Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-06-08 14:49:59 +02:00
Tilman Schmidt
4e32997205 isdn: rename capi_ctr_reseted() to capi_ctr_down()
Change the name of the Kernel CAPI exported function capi_ctr_reseted()
to something representing its purpose better.

Impact: renaming, no functional change
Signed-off-by: Tilman Schmidt <tilman@imap.cc>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-06-08 00:45:50 -07:00
Dave Young
4c71318948 Bluetooth: Remove useless flush_work() causing lockdep warnings
The calls to flush_work() are pointless in a single thread workqueue
and they are actually causing a lockdep warning.

=============================================
[ INFO: possible recursive locking detected ]
2.6.30-rc6-02911-gbb803cf #16
---------------------------------------------
bluetooth/2518 is trying to acquire lock:
 (bluetooth){+.+.+.}, at: [<c0130c14>] flush_work+0x28/0xb0

but task is already holding lock:
 (bluetooth){+.+.+.}, at: [<c0130424>] worker_thread+0x149/0x25e

other info that might help us debug this:
2 locks held by bluetooth/2518:
 #0:  (bluetooth){+.+.+.}, at: [<c0130424>] worker_thread+0x149/0x25e
 #1:  (&conn->work_del){+.+...}, at: [<c0130424>] worker_thread+0x149/0x25e

stack backtrace:
Pid: 2518, comm: bluetooth Not tainted 2.6.30-rc6-02911-gbb803cf #16
Call Trace:
 [<c03d64d9>] ? printk+0xf/0x11
 [<c0140d96>] __lock_acquire+0x7ce/0xb1b
 [<c0141173>] lock_acquire+0x90/0xad
 [<c0130c14>] ? flush_work+0x28/0xb0
 [<c0130c2e>] flush_work+0x42/0xb0
 [<c0130c14>] ? flush_work+0x28/0xb0
 [<f8b84966>] del_conn+0x1c/0x84 [bluetooth]
 [<c0130469>] worker_thread+0x18e/0x25e
 [<c0130424>] ? worker_thread+0x149/0x25e
 [<f8b8494a>] ? del_conn+0x0/0x84 [bluetooth]
 [<c0133843>] ? autoremove_wake_function+0x0/0x33
 [<c01302db>] ? worker_thread+0x0/0x25e
 [<c013355a>] kthread+0x45/0x6b
 [<c0133515>] ? kthread+0x0/0x6b
 [<c01034a7>] kernel_thread_helper+0x7/0x10

Based on a report by Oliver Hartkopp <oliver@hartkopp.net>

Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Tested-by: Oliver Hartkopp <oliver@hartkopp.net>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-05-27 09:15:57 +02:00
Marcel Holtmann
3d7a9d1c7e Bluetooth: Don't trigger disconnect timeout for security mode 3 pairing
A remote device in security mode 3 that tries to connect will require
the pairing during the connection setup phase. The disconnect timeout
is now triggered within 10 milliseconds and causes the pairing to fail.

If a connection is not fully established and a PIN code request is
received, don't trigger the disconnect timeout. The either successful
or failing connection complete event will make sure that the timeout
is triggered at the right time.

The biggest problem with security mode 3 is that many Bluetooth 2.0
device and before use a temporary security mode 3 for dedicated
bonding.

Based on a report by Johan Hedberg <johan.hedberg@nokia.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: Johan Hedberg <johan.hedberg@nokia.com>
2009-05-09 18:09:52 -07:00
Marcel Holtmann
1b0336bb36 Bluetooth: Don't use hci_acl_connect_cancel() for incoming connections
The connection setup phase takes around 2 seconds or longer and in
that time it is possible that the need for an ACL connection is no
longer present. If that happens then, the connection attempt will
be canceled.

This only applies to outgoing connections, but currently it can also
be triggered by incoming connection. Don't call hci_acl_connect_cancel()
on incoming connection since these have to be either accepted or rejected
in this state. Once they are successfully connected they need to be
fully disconnected anyway.

Also remove the wrong hci_acl_disconn() call for SCO and eSCO links
since at this stage they can't be disconnected either, because the
connection handle is still unknown.

Based on a report by Johan Hedberg <johan.hedberg@nokia.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: Johan Hedberg <johan.hedberg@nokia.com>
2009-05-09 18:09:45 -07:00
Marcel Holtmann
384943ec1b Bluetooth: Fix wrong module refcount when connection setup fails
The module refcount is increased by hci_dev_hold() call in hci_conn_add()
and decreased by hci_dev_put() call in del_conn(). In case the connection
setup fails, hci_dev_put() is never called.

Procedure to reproduce the issue:

  # hciconfig hci0 up
  # lsmod | grep btusb                   -> "used by" refcount = 1

  # hcitool cc <non-exisiting bdaddr>    -> will get timeout

  # lsmod | grep btusb                   -> "used by" refcount = 2
  # hciconfig hci0 down
  # lsmod | grep btusb                   -> "used by" refcount = 1
  # rmmod btusb                          -> ERROR: Module btusb is in use

The hci_dev_put() call got moved into del_conn() with the 2.6.25 kernel
to fix an issue with hci_dev going away before hci_conn. However that
change was wrong and introduced this problem.

When calling hci_conn_del() it has to call hci_dev_put() after freeing
the connection details. This handling should be fully symmetric. The
execution of del_conn() is done in a work queue and needs it own calls
to hci_dev_hold() and hci_dev_put() to ensure that the hci_dev stays
until the connection cleanup has been finished.

Based on a report by Bing Zhao <bzhao@marvell.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: Bing Zhao <bzhao@marvell.com>
2009-05-09 18:09:38 -07:00
Marcel Holtmann
457ca7bb6b Bluetooth: Move dev_set_name() to a context that can sleep
Setting the name of a sysfs device has to be done in a context that can
actually sleep. It allocates its memory with GFP_KERNEL. Previously it
was a static (size limited) string and that got changed to accommodate
longer device names. So move the dev_set_name() just before calling
device_add() which is executed in a work queue.

This fixes the following error:

[  110.012125] BUG: sleeping function called from invalid context at mm/slub.c:1595
[  110.012135] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
[  110.012141] 2 locks held by swapper/0:
[  110.012145]  #0:  (hci_task_lock){++.-.+}, at: [<ffffffffa01f822f>] hci_rx_task+0x2f/0x2d0 [bluetooth]
[  110.012173]  #1:  (&hdev->lock){+.-.+.}, at: [<ffffffffa01fb9e2>] hci_event_packet+0x72/0x25c0 [bluetooth]
[  110.012198] Pid: 0, comm: swapper Tainted: G        W 2.6.30-rc4-g953cdaa #1
[  110.012203] Call Trace:
[  110.012207]  <IRQ>  [<ffffffff8023eabd>] __might_sleep+0x14d/0x170
[  110.012228]  [<ffffffff802cfbe1>] __kmalloc+0x111/0x170
[  110.012239]  [<ffffffff803c2094>] kvasprintf+0x64/0xb0
[  110.012248]  [<ffffffff803b7a5b>] kobject_set_name_vargs+0x3b/0xa0
[  110.012257]  [<ffffffff80465326>] dev_set_name+0x76/0xa0
[  110.012273]  [<ffffffffa01fb9e2>] ? hci_event_packet+0x72/0x25c0 [bluetooth]
[  110.012289]  [<ffffffffa01ffc1d>] hci_conn_add_sysfs+0x3d/0x70 [bluetooth]
[  110.012303]  [<ffffffffa01fba2c>] hci_event_packet+0xbc/0x25c0 [bluetooth]
[  110.012312]  [<ffffffff80516eb0>] ? sock_def_readable+0x80/0xa0
[  110.012328]  [<ffffffffa01fee0c>] ? hci_send_to_sock+0xfc/0x1c0 [bluetooth]
[  110.012343]  [<ffffffff80516eb0>] ? sock_def_readable+0x80/0xa0
[  110.012347]  [<ffffffff805e88c5>] ? _read_unlock+0x75/0x80
[  110.012354]  [<ffffffffa01fee0c>] ? hci_send_to_sock+0xfc/0x1c0 [bluetooth]
[  110.012360]  [<ffffffffa01f8403>] hci_rx_task+0x203/0x2d0 [bluetooth]
[  110.012365]  [<ffffffff80250ab5>] tasklet_action+0xb5/0x160
[  110.012369]  [<ffffffff8025116c>] __do_softirq+0x9c/0x150
[  110.012372]  [<ffffffff805e850f>] ? _spin_unlock+0x3f/0x80
[  110.012376]  [<ffffffff8020cbbc>] call_softirq+0x1c/0x30
[  110.012380]  [<ffffffff8020f01d>] do_softirq+0x8d/0xe0
[  110.012383]  [<ffffffff80250df5>] irq_exit+0xc5/0xe0
[  110.012386]  [<ffffffff8020e71d>] do_IRQ+0x9d/0x120
[  110.012389]  [<ffffffff8020c3d3>] ret_from_intr+0x0/0xf
[  110.012391]  <EOI>  [<ffffffff80431832>] ? acpi_idle_enter_bm+0x264/0x2a6
[  110.012399]  [<ffffffff80431828>] ? acpi_idle_enter_bm+0x25a/0x2a6
[  110.012403]  [<ffffffff804f50d5>] ? cpuidle_idle_call+0xc5/0x130
[  110.012407]  [<ffffffff8020a4b4>] ? cpu_idle+0xc4/0x130
[  110.012411]  [<ffffffff805d2268>] ? rest_init+0x88/0xb0
[  110.012416]  [<ffffffff807e2fbd>] ? start_kernel+0x3b5/0x412
[  110.012420]  [<ffffffff807e2281>] ? x86_64_start_reservations+0x91/0xb5
[  110.012424]  [<ffffffff807e2394>] ? x86_64_start_kernel+0xef/0x11b

Based on a report by Davide Pesavento <davidepesa@gmail.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: Hugo Mildenberger <hugo.mildenberger@namir.de>
Tested-by: Bing Zhao <bzhao@marvell.com>
2009-05-05 13:26:08 -07:00
Marcel Holtmann
a67e899cf3 Bluetooth: Fix issue with sysfs handling for connections
Due to a semantic changes in flush_workqueue() the current approach of
synchronizing the sysfs handling for connections doesn't work anymore. The
whole approach is actually fully broken and based on assumptions that are
no longer valid.

With the introduction of Simple Pairing support, the creation of low-level
ACL links got changed. This change invalidates the reason why in the past
two independent work queues have been used for adding/removing sysfs
devices. The adding of the actual sysfs device is now postponed until the
host controller successfully assigns an unique handle to that link. So
the real synchronization happens inside the controller and not the host.

The only left-over problem is that some internals of the sysfs device
handling are not initialized ahead of time. This leaves potential access
to invalid data and can cause various NULL pointer dereferences. To fix
this a new function makes sure that all sysfs details are initialized
when an connection attempt is made. The actual sysfs device is only
registered when the connection has been successfully established. To
avoid a race condition with the registration, the check if a device is
registered has been moved into the removal work.

As an extra protection two flush_work() calls are left in place to
make sure a previous add/del work has been completed first.

Based on a report by Marc Pignat <marc.pignat@hevs.ch>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: Justin P. Mattock <justinmattock@gmail.com>
Tested-by: Roger Quadros <ext-roger.quadros@nokia.com>
Tested-by: Marc Pignat <marc.pignat@hevs.ch>
2009-05-04 14:29:02 -07:00
Marcel Holtmann
3fdca1e137 Bluetooth: Fix connection establishment with low security requirement
The Bluetooth 2.1 specification introduced four different security modes
that can be mapped using Legacy Pairing and Simple Pairing. With the
usage of Simple Pairing it is required that all connections (except
the ones for SDP) are encrypted. So even the low security requirement
mandates an encrypted connection when using Simple Pairing. When using
Legacy Pairing (for Bluetooth 2.0 devices and older) this is not required
since it causes interoperability issues.

To support this properly the low security requirement translates into
different host controller transactions depending if Simple Pairing is
supported or not. However in case of Simple Pairing the command to
switch on encryption after a successful authentication is not triggered
for the low security mode. This patch fixes this and actually makes
the logic to differentiate between Simple Pairing and Legacy Pairing
a lot simpler.

Based on a report by Ville Tervo <ville.tervo@nokia.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-04-28 09:31:39 -07:00
Marcel Holtmann
052b30b0a8 Bluetooth: Add different pairing timeout for Legacy Pairing
The Bluetooth stack uses a reference counting for all established ACL
links and if no user (L2CAP connection) is present, the link will be
terminated to save power. The problem part is the dedicated pairing
when using Legacy Pairing (Bluetooth 2.0 and before). At that point
no user is present and pairing attempts will be disconnected within
10 seconds or less. In previous kernel version this was not a problem
since the disconnect timeout wasn't triggered on incoming connections
for the first time. However this caused issues with broken host stacks
that kept the connections around after dedicated pairing. When the
support for Simple Pairing got added, the link establishment procedure
needed to be changed and now causes issues when using Legacy Pairing

When using Simple Pairing it is possible to do a proper reference
counting of ACL link users. With Legacy Pairing this is not possible
since the specification is unclear in some areas and too many broken
Bluetooth devices have already been deployed. So instead of trying to
deal with all the broken devices, a special pairing timeout will be
introduced that increases the timeout to 60 seconds when pairing is
triggered.

If a broken devices now puts the stack into an unforeseen state, the
worst that happens is the disconnect timeout triggers after 120 seconds
instead of 4 seconds. This allows successful pairings with legacy and
broken devices now.

Based on a report by Johan Hedberg <johan.hedberg@nokia.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-04-28 09:31:38 -07:00
Roger Quadros
f3784d834c Bluetooth: Ensure that HCI sysfs add/del is preempt safe
Use a different work_struct variables for add_conn() and del_conn() and
use single work queue instead of two for adding and deleting connections.

It eliminates the following error on a preemptible kernel:

[  204.358032] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
[  204.370697] pgd = c0004000
[  204.373443] [0000000c] *pgd=00000000
[  204.378601] Internal error: Oops: 17 [#1] PREEMPT
[  204.383361] Modules linked in: vfat fat rfcomm sco l2cap sd_mod scsi_mod iphb pvr2d drm omaplfb ps
[  204.438537] CPU: 0    Not tainted  (2.6.28-maemo2 #1)
[  204.443664] PC is at klist_put+0x2c/0xb4
[  204.447601] LR is at klist_put+0x18/0xb4
[  204.451568] pc : [<c0270f08>]    lr : [<c0270ef4>]    psr: a0000113
[  204.451568] sp : cf1b3f10  ip : cf1b3f10  fp : cf1b3f2c
[  204.463104] r10: 00000000  r9 : 00000000  r8 : bf08029c
[  204.468353] r7 : c7869200  r6 : cfbe2690  r5 : c78692c8  r4 : 00000001
[  204.474945] r3 : 00000001  r2 : cf1b2000  r1 : 00000001  r0 : 00000000
[  204.481506] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment kernel
[  204.488861] Control: 10c5387d  Table: 887fc018  DAC: 00000017
[  204.494628] Process btdelconn (pid: 515, stack limit = 0xcf1b22e0)

Signed-off-by: Roger Quadros <ext-roger.quadros@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-04-28 09:31:38 -07:00
Marcel Holtmann
9499237a1c Bluetooth: Add workaround for wrong HCI event in eSCO setup
The Broadcom chips with 2.1 firmware handle the fallback case to a SCO
link wrongly when setting up eSCO connections.

  < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
      handle 11 voice setting 0x0060
  > HCI Event: Command Status (0x0f) plen 4
      Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
  > HCI Event: Connect Complete (0x03) plen 11
      status 0x00 handle 1 bdaddr 00:1E:3A:xx:xx:xx type SCO encrypt 0x01

The Link Manager negotiates the fallback to SCO, but then sends out
a Connect Complete event. This is wrong and the Link Manager should
actually send a Synchronous Connection Complete event if the Setup
Synchronous Connection has been used. Only the remote side is allowed
to use Connect Complete to indicate the missing support for eSCO in
the host stack.

This patch adds a workaround for this which clearly should not be
needed, but reality is that broken Broadcom devices are deployed.

Based on a report by Ville Tervo <ville.tervo@nokia.com>

Signed-off-by: Marcel Holtman <marcel@holtmann.org>
2009-04-19 19:30:03 +02:00
Marcel Holtmann
732547f96e Bluetooth: Fallback from eSCO to SCO on unspecified error
Some Bluetooth chips (like the ones from Texas Instruments) don't do
proper eSCO negotiations inside the Link Manager. They just return an
error code and in case of the Kyocera ED-8800 headset it is just a
random error.

  < HCI Command: Setup Synchronous Connection 0x01|0x0028) plen 17
    handle 1 voice setting 0x0060
  > HCI Event: Command Status (0x0f) plen 4
    Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
  > HCI Event: Synchronous Connect Complete (0x2c) plen 17
    status 0x1f handle 257 bdaddr 00:14:0A:xx:xx:xx type eSCO
    Error: Unspecified Error

In these cases it is up to the host stack to fallback to a SCO setup
and so retry with SCO parameters.

Based on a report by Nick Pelly <npelly@google.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-04-19 19:14:14 +02:00
Johan Hedberg
e2139b3272 Bluetooth: Fix removing of RFCOMM DLC timer with DEFER_SETUP
There is a missing call to rfcomm_dlc_clear_timer in the case that
DEFER_SETUP is used and so the connection gets disconnected after the
timeout even if it was successfully accepted previously.

This patch adds a call to rfcomm_dlc_clear_timer to rfcomm_dlc_accept
which will get called when the user accepts the connection by calling
read() on the socket.

Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-04-19 18:56:45 +02:00
Alexey Dobriyan
0f043a81eb proc tty: remove struct tty_operations::read_proc
struct tty_operations::proc_fops took it's place and there is one less
create_proc_read_entry() user now!

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-04-01 08:59:10 -07:00
David S. Miller
08abe18af1 Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
Conflicts:
	drivers/net/wimax/i2400m/usb-notif.c
2009-03-26 15:23:24 -07:00
Cornelia Huck
ffa6a7054d Driver core: Fix device_move() vs. dpm list ordering, v2
dpm_list currently relies on the fact that child devices will
be registered after their parents to get a correct suspend
order. Using device_move() however destroys this assumption, as
an already registered device may be moved under a newly registered
one.

This patch adds a new argument to device_move(), allowing callers
to specify how dpm_list should be adapted.

Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-24 16:38:26 -07:00
Wei Yongjun
7585b97a48 Bluetooth: Remove some pointless conditionals before kfree_skb()
Remove some pointless conditionals before kfree_skb().

Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:49 +01:00
Dave Young
2ae9a6be5f Bluetooth: Move hci_conn_del_sysfs() back to avoid device destruct too early
The following commit introduce a regression:

	commit 7d0db0a373
	Author: Marcel Holtmann <marcel@holtmann.org>
	Date:   Mon Jul 14 20:13:51 2008 +0200

		[Bluetooth] Use a more unique bus name for connections

I get panic as following (by netconsole):

[ 2709.344034] usb 5-1: new full speed USB device using uhci_hcd and address 4
[ 2709.505776] usb 5-1: configuration #1 chosen from 1 choice
[ 2709.569207] Bluetooth: Generic Bluetooth USB driver ver 0.4
[ 2709.570169] usbcore: registered new interface driver btusb
[ 2845.742781] BUG: unable to handle kernel paging request at 6b6b6c2f
[ 2845.742958] IP: [<c015515c>] __lock_acquire+0x6c/0xa80
[ 2845.743087] *pde = 00000000
[ 2845.743206] Oops: 0002 [#1] SMP
[ 2845.743377] last sysfs file: /sys/class/bluetooth/hci0/hci0:6/type
[ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev
[ 2845.743742]
[ 2845.743742] Pid: 0, comm: swapper Not tainted (2.6.29-rc5-smp #54) Dell DM051
[ 2845.743742] EIP: 0060:[<c015515c>] EFLAGS: 00010002 CPU: 0
[ 2845.743742] EIP is at __lock_acquire+0x6c/0xa80
[ 2845.743742] EAX: 00000046 EBX: 00000046 ECX: 6b6b6b6b EDX: 00000002
[ 2845.743742] ESI: 6b6b6b6b EDI: 00000000 EBP: c064fd14 ESP: c064fcc8
[ 2845.743742]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 2845.743742] Process swapper (pid: 0, ti=c064e000 task=c05d1400 task.ti=c064e000)
[ 2845.743742] Stack:
[ 2845.743742]  c05d1400 00000002 c05d1400 00000001 00000002 00000000 f65388dc c05d1400
[ 2845.743742]  6b6b6b6b 00000292 c064fd0c c0153732 00000000 00000000 00000001 f700fa50
[ 2845.743742]  00000046 00000000 00000000 c064fd40 c0155be6 00000000 00000002 00000001
[ 2845.743742] Call Trace:
[ 2845.743742]  [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0
[ 2845.743742]  [<c0155be6>] ? lock_acquire+0x76/0xa0
[ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742]  [<c046c885>] ? _spin_lock_irqsave+0x45/0x80
[ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742]  [<c03e1f94>] ? skb_queue_purge+0x14/0x20
[ 2845.743742]  [<f8171f5a>] ? hci_conn_del+0x10a/0x1c0 [bluetooth]
[ 2845.743742]  [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap]
[ 2845.743742]  [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth]
[ 2845.743742]  [<f8175758>] ? hci_event_packet+0x5f8/0x31c0 [bluetooth]
[ 2845.743742]  [<c03dfe19>] ? sock_def_readable+0x59/0x80
[ 2845.743742]  [<c046c14d>] ? _read_unlock+0x1d/0x20
[ 2845.743742]  [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth]
[ 2845.743742]  [<c015388b>] ? trace_hardirqs_on+0xb/0x10
[ 2845.743742]  [<f816fa6a>] ? hci_rx_task+0x2ba/0x490 [bluetooth]
[ 2845.743742]  [<c0133661>] ? tasklet_action+0x31/0xc0
[ 2845.743742]  [<c013367c>] ? tasklet_action+0x4c/0xc0
[ 2845.743742]  [<c0132eb7>] ? __do_softirq+0xa7/0x170
[ 2845.743742]  [<c0116dec>] ? ack_apic_level+0x5c/0x1c0
[ 2845.743742]  [<c0132fd7>] ? do_softirq+0x57/0x60
[ 2845.743742]  [<c01333dc>] ? irq_exit+0x7c/0x90
[ 2845.743742]  [<c01055bb>] ? do_IRQ+0x4b/0x90
[ 2845.743742]  [<c01333d5>] ? irq_exit+0x75/0x90
[ 2845.743742]  [<c010392c>] ? common_interrupt+0x2c/0x34
[ 2845.743742]  [<c010a14f>] ? mwait_idle+0x4f/0x70
[ 2845.743742]  [<c0101c05>] ? cpu_idle+0x65/0xb0
[ 2845.743742]  [<c045731e>] ? rest_init+0x4e/0x60
[ 2845.743742] Code: 0f 84 69 02 00 00 83 ff 07 0f 87 1e 06 00 00 85 ff 0f 85 08 05 00 00 8b 4d cc 8b 49 04 85 c9 89 4d d4 0f 84 f7 04 00 00 8b 75 d4 <f0> ff 86 c4 00 00 00 89 f0 e8 56 a9 ff ff 85 c0 0f 85 6e 03 00
[ 2845.743742] EIP: [<c015515c>] __lock_acquire+0x6c/0xa80 SS:ESP 0068:c064fcc8
[ 2845.743742] ---[ end trace 4c985b38f022279f ]---
[ 2845.743742] Kernel panic - not syncing: Fatal exception in interrupt
[ 2845.743742] ------------[ cut here ]------------
[ 2845.743742] WARNING: at kernel/smp.c:329 smp_call_function_many+0x151/0x200()
[ 2845.743742] Hardware name: Dell DM051
[ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev
[ 2845.743742] Pid: 0, comm: swapper Tainted: G      D    2.6.29-rc5-smp #54
[ 2845.743742] Call Trace:
[ 2845.743742]  [<c012e076>] warn_slowpath+0x86/0xa0
[ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
[ 2845.743742]  [<c0146384>] ? up+0x14/0x40
[ 2845.743742]  [<c012e661>] ? release_console_sem+0x31/0x1e0
[ 2845.743742]  [<c046c8ab>] ? _spin_lock_irqsave+0x6b/0x80
[ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
[ 2845.743742]  [<c046c900>] ? _read_lock_irqsave+0x40/0x80
[ 2845.743742]  [<c012e7f2>] ? release_console_sem+0x1c2/0x1e0
[ 2845.743742]  [<c0146384>] ? up+0x14/0x40
[ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
[ 2845.743742]  [<c046a3d7>] ? __mutex_unlock_slowpath+0x97/0x160
[ 2845.743742]  [<c046a563>] ? mutex_trylock+0xb3/0x180
[ 2845.743742]  [<c046a4a8>] ? mutex_unlock+0x8/0x10
[ 2845.743742]  [<c015b991>] smp_call_function_many+0x151/0x200
[ 2845.743742]  [<c010a1a0>] ? stop_this_cpu+0x0/0x40
[ 2845.743742]  [<c015ba61>] smp_call_function+0x21/0x30
[ 2845.743742]  [<c01137ae>] native_smp_send_stop+0x1e/0x50
[ 2845.743742]  [<c012e0f5>] panic+0x55/0x110
[ 2845.743742]  [<c01065a8>] oops_end+0xb8/0xc0
[ 2845.743742]  [<c010668f>] die+0x4f/0x70
[ 2845.743742]  [<c011a8c9>] do_page_fault+0x269/0x610
[ 2845.743742]  [<c011a660>] ? do_page_fault+0x0/0x610
[ 2845.743742]  [<c046cbaf>] error_code+0x77/0x7c
[ 2845.743742]  [<c015515c>] ? __lock_acquire+0x6c/0xa80
[ 2845.743742]  [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0
[ 2845.743742]  [<c0155be6>] lock_acquire+0x76/0xa0
[ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742]  [<c046c885>] _spin_lock_irqsave+0x45/0x80
[ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742]  [<c03e1aad>] skb_dequeue+0x1d/0x70
[ 2845.743742]  [<c03e1f94>] skb_queue_purge+0x14/0x20
[ 2845.743742]  [<f8171f5a>] hci_conn_del+0x10a/0x1c0 [bluetooth]
[ 2845.743742]  [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap]
[ 2845.743742]  [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth]
[ 2845.743742]  [<f8175758>] hci_event_packet+0x5f8/0x31c0 [bluetooth]
[ 2845.743742]  [<c03dfe19>] ? sock_def_readable+0x59/0x80
[ 2845.743742]  [<c046c14d>] ? _read_unlock+0x1d/0x20
[ 2845.743742]  [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth]
[ 2845.743742]  [<c015388b>] ? trace_hardirqs_on+0xb/0x10
[ 2845.743742]  [<f816fa6a>] hci_rx_task+0x2ba/0x490 [bluetooth]
[ 2845.743742]  [<c0133661>] ? tasklet_action+0x31/0xc0
[ 2845.743742]  [<c013367c>] tasklet_action+0x4c/0xc0
[ 2845.743742]  [<c0132eb7>] __do_softirq+0xa7/0x170
[ 2845.743742]  [<c0116dec>] ? ack_apic_level+0x5c/0x1c0
[ 2845.743742]  [<c0132fd7>] do_softirq+0x57/0x60
[ 2845.743742]  [<c01333dc>] irq_exit+0x7c/0x90
[ 2845.743742]  [<c01055bb>] do_IRQ+0x4b/0x90
[ 2845.743742]  [<c01333d5>] ? irq_exit+0x75/0x90
[ 2845.743742]  [<c010392c>] common_interrupt+0x2c/0x34
[ 2845.743742]  [<c010a14f>] ? mwait_idle+0x4f/0x70
[ 2845.743742]  [<c0101c05>] cpu_idle+0x65/0xb0
[ 2845.743742]  [<c045731e>] rest_init+0x4e/0x60
[ 2845.743742] ---[ end trace 4c985b38f02227a0 ]---
[ 2845.743742] ------------[ cut here ]------------
[ 2845.743742] WARNING: at kernel/smp.c:226 smp_call_function_single+0x8e/0x110()
[ 2845.743742] Hardware name: Dell DM051
[ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev
[ 2845.743742] Pid: 0, comm: swapper Tainted: G      D W  2.6.29-rc5-smp #54
[ 2845.743742] Call Trace:
[ 2845.743742]  [<c012e076>] warn_slowpath+0x86/0xa0
[ 2845.743742]  [<c012e000>] ? warn_slowpath+0x10/0xa0
[ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
[ 2845.743742]  [<c0146384>] ? up+0x14/0x40
[ 2845.743742]  [<c012e661>] ? release_console_sem+0x31/0x1e0
[ 2845.743742]  [<c046c8ab>] ? _spin_lock_irqsave+0x6b/0x80
[ 2845.743742]  [<c015041b>] ? trace_hardirqs_off+0xb/0x10
[ 2845.743742]  [<c046c900>] ? _read_lock_irqsave+0x40/0x80
[ 2845.743742]  [<c012e7f2>] ? release_console_sem+0x1c2/0x1e0
[ 2845.743742]  [<c0146384>] ? up+0x14/0x40
[ 2845.743742]  [<c015b7be>] smp_call_function_single+0x8e/0x110
[ 2845.743742]  [<c010a1a0>] ? stop_this_cpu+0x0/0x40
[ 2845.743742]  [<c026d23f>] ? cpumask_next_and+0x1f/0x40
[ 2845.743742]  [<c015b95a>] smp_call_function_many+0x11a/0x200
[ 2845.743742]  [<c010a1a0>] ? stop_this_cpu+0x0/0x40
[ 2845.743742]  [<c015ba61>] smp_call_function+0x21/0x30
[ 2845.743742]  [<c01137ae>] native_smp_send_stop+0x1e/0x50
[ 2845.743742]  [<c012e0f5>] panic+0x55/0x110
[ 2845.743742]  [<c01065a8>] oops_end+0xb8/0xc0
[ 2845.743742]  [<c010668f>] die+0x4f/0x70
[ 2845.743742]  [<c011a8c9>] do_page_fault+0x269/0x610
[ 2845.743742]  [<c011a660>] ? do_page_fault+0x0/0x610
[ 2845.743742]  [<c046cbaf>] error_code+0x77/0x7c
[ 2845.743742]  [<c015515c>] ? __lock_acquire+0x6c/0xa80
[ 2845.743742]  [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0
[ 2845.743742]  [<c0155be6>] lock_acquire+0x76/0xa0
[ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742]  [<c046c885>] _spin_lock_irqsave+0x45/0x80
[ 2845.743742]  [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742]  [<c03e1aad>] skb_dequeue+0x1d/0x70
[ 2845.743742]  [<c03e1f94>] skb_queue_purge+0x14/0x20
[ 2845.743742]  [<f8171f5a>] hci_conn_del+0x10a/0x1c0 [bluetooth]
[ 2845.743742]  [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap]
[ 2845.743742]  [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth]
[ 2845.743742]  [<f8175758>] hci_event_packet+0x5f8/0x31c0 [bluetooth]
[ 2845.743742]  [<c03dfe19>] ? sock_def_readable+0x59/0x80
[ 2845.743742]  [<c046c14d>] ? _read_unlock+0x1d/0x20
[ 2845.743742]  [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth]
[ 2845.743742]  [<c015388b>] ? trace_hardirqs_on+0xb/0x10
[ 2845.743742]  [<f816fa6a>] hci_rx_task+0x2ba/0x490 [bluetooth]
[ 2845.743742]  [<c0133661>] ? tasklet_action+0x31/0xc0
[ 2845.743742]  [<c013367c>] tasklet_action+0x4c/0xc0
[ 2845.743742]  [<c0132eb7>] __do_softirq+0xa7/0x170
[ 2845.743742]  [<c0116dec>] ? ack_apic_level+0x5c/0x1c0
[ 2845.743742]  [<c0132fd7>] do_softirq+0x57/0x60
[ 2845.743742]  [<c01333dc>] irq_exit+0x7c/0x90
[ 2845.743742]  [<c01055bb>] do_IRQ+0x4b/0x90
[ 2845.743742]  [<c01333d5>] ? irq_exit+0x75/0x90
[ 2845.743742]  [<c010392c>] common_interrupt+0x2c/0x34
[ 2845.743742]  [<c010a14f>] ? mwait_idle+0x4f/0x70
[ 2845.743742]  [<c0101c05>] cpu_idle+0x65/0xb0
[ 2845.743742]  [<c045731e>] rest_init+0x4e/0x60
[ 2845.743742] ---[ end trace 4c985b38f02227a1 ]---
[ 2845.743742] Rebooting in 3 seconds..

My logitec bluetooth mouse trying connect to pc, but
pc side reject the connection again and again. then panic happens.

The reason is due to hci_conn_del_sysfs now called in hci_event_packet,
the del work is done in a workqueue, so it's possible done before
skb_queue_purge called.

I move the hci_conn_del_sysfs after skb_queue_purge just as that before
marcel's commit.

Remove the hci_conn_del_sysfs in hci_conn_hash_flush as well due to
hci_conn_del will deal with the work.

Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:49 +01:00
Marcel Holtmann
2526d3d8b2 Bluetooth: Permit BT_SECURITY also for L2CAP raw sockets
Userspace pairing code can be simplified if it doesn't have to fall
back to using L2CAP_LM in the case of L2CAP raw sockets. This patch
allows the BT_SECURITY socket option to be used for these sockets.

Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:48 +01:00
Marcel Holtmann
37e62f5516 Bluetooth: Fix RFCOMM usage of in-kernel L2CAP sockets
The CID value of L2CAP sockets need to be set to zero. All userspace
applications do this via memset() on the sockaddr_l2 structure. The
RFCOMM implementation uses in-kernel L2CAP sockets and so it has to
make sure that l2_cid is set to zero.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:48 +01:00
Marcel Holtmann
2a517ca687 Bluetooth: Disallow usage of L2CAP CID setting for now
In the future the L2CAP layer will have full support for fixed channels
and right now it already can export the channel assignment, but for the
functions bind() and connect() the usage of only CID 0 is allowed. This
allows an easy detection if the kernel supports fixed channels or not,
because otherwise it would impossible for application to tell.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:47 +01:00
Marcel Holtmann
8bf4794174 Bluetooth: Change RFCOMM to use BT_CONNECT2 for BT_DEFER_SETUP
When BT_DEFER_SETUP is enabled on a RFCOMM socket, then switch its
current state from BT_OPEN to BT_CONNECT2. This gives the Bluetooth
core a unified way to handle L2CAP and RFCOMM sockets. The BT_CONNECT2
state is designated for incoming connections.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:47 +01:00
Marcel Holtmann
d5f2d2be68 Bluetooth: Fix poll() misbehavior when using BT_DEFER_SETUP
When BT_DEFER_SETUP has been enabled on a Bluetooth socket it keeps
signaling POLLIN all the time. This is a wrong behavior. The POLLIN
should only be signaled if the client socket is in BT_CONNECT2 state
and the parent has been BT_DEFER_SETUP enabled.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:46 +01:00
Marcel Holtmann
96a3183322 Bluetooth: Set authentication requirement before requesting it
The authentication requirement got only updated when the security level
increased. This is a wrong behavior. The authentication requirement is
read by the Bluetooth daemon to make proper decisions when handling the
IO capabilities exchange. So set the value that is currently expected by
the higher layers like L2CAP and RFCOMM.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:44 +01:00
Marcel Holtmann
00ae4af91d Bluetooth: Fix authentication requirements for L2CAP security check
The L2CAP layer can trigger the authentication via an ACL connection or
later on to increase the security level. When increasing the security
level it didn't use the same authentication requirements when triggering
a new ACL connection. Make sure that exactly the same authentication
requirements are used. The only exception here are the L2CAP raw sockets
which are only used for dedicated bonding.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:43 +01:00
Marcel Holtmann
2950f21acb Bluetooth: Ask upper layers for HCI disconnect reason
Some of the qualification tests demand that in case of failures in L2CAP
the HCI disconnect should indicate a reason why L2CAP fails. This is a
bluntly layer violation since multiple L2CAP connections could be using
the same ACL and thus forcing a disconnect reason is not a good idea.

To comply with the Bluetooth test specification, the disconnect reason
is now stored in the L2CAP connection structure and every time a new
L2CAP channel is added it will set back to its default. So only in the
case where the L2CAP channel with the disconnect reason is really the
last one, it will propagated to the HCI layer.

The HCI layer has been extended with a disconnect indication that allows
it to ask upper layers for a disconnect reason. The upper layer must not
support this callback and in that case it will nicely default to the
existing behavior. If an upper layer like L2CAP can provide a disconnect
reason that one will be used to disconnect the ACL or SCO link.

No modification to the ACL disconnect timeout have been made. So in case
of Linux to Linux connection the initiator will disconnect the ACL link
before the acceptor side can signal the specific disconnect reason. That
is perfectly fine since Linux doesn't make use of this value anyway. The
L2CAP layer has a perfect valid error code for rejecting connection due
to a security violation. It is unclear why the Bluetooth specification
insists on having specific HCI disconnect reason.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:43 +01:00
Marcel Holtmann
f29972de8e Bluetooth: Add CID field to L2CAP socket address structure
In preparation for L2CAP fixed channel support, the CID value of a
L2CAP connection needs to be accessible via the socket interface. The
CID is the connection identifier and exists as source and destination
value. So extend the L2CAP socket address structure with this field and
change getsockname() and getpeername() to fill it in.

The bind() and connect() functions have been modified to handle L2CAP
socket address structures of variable sizes. This makes them future
proof if additional fields need to be added.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:42 +01:00
Marcel Holtmann
e1027a7c69 Bluetooth: Request L2CAP fixed channel list if available
If the extended features mask indicates support for fixed channels,
request the list of available fixed channels. This also enables the
fixed channel features bit so remote implementations can request
information about it. Currently only the signal channel will be
listed.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:42 +01:00
Marcel Holtmann
435fef20ac Bluetooth: Don't enforce authentication for L2CAP PSM 1 and 3
The recommendation for the L2CAP PSM 1 (SDP) is to not use any kind
of authentication or encryption. So don't trigger authentication
for incoming and outgoing SDP connections.

For L2CAP PSM 3 (RFCOMM) there is no clear requirement, but with
Bluetooth 2.1 the initiator is required to enable authentication
and encryption first and this gets enforced. So there is no need
to trigger an additional authentication step. The RFCOMM service
security will make sure that a secure enough link key is present.

When the encryption gets enabled after the SDP connection setup,
then switch the security level from SDP to low security.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:41 +01:00
Marcel Holtmann
6a8d3010b3 Bluetooth: Fix double L2CAP connection request
If the remote L2CAP server uses authentication pending stage and
encryption is enabled it can happen that a L2CAP connection request is
sent twice due to a race condition in the connection state machine.

When the remote side indicates any kind of connection pending, then
track this state and skip sending of L2CAP commands for this period.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:41 +01:00
Marcel Holtmann
984947dc64 Bluetooth: Fix race condition with L2CAP information request
When two L2CAP connections are requested quickly after the ACL link has
been established there exists a window for a race condition where a
connection request is sent before the information response has been
received. Any connection request should only be sent after an exchange
of the extended features mask has been finished.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:41 +01:00
Marcel Holtmann
657e17b03c Bluetooth: Set authentication requirements if not available
When no authentication requirements are selected, but an outgoing or
incoming connection has requested any kind of security enforcement,
then set these authentication requirements.

This ensures that the userspace always gets informed about the
authentication requirements (if available). Only when no security
enforcement has happened, the kernel will signal invalid requirements.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:40 +01:00
Marcel Holtmann
0684e5f9fb Bluetooth: Use general bonding whenever possible
When receiving incoming connection to specific services, always use
general bonding. This ensures that the link key gets stored and can be
used for further authentications.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:40 +01:00
Marcel Holtmann
efc7688b55 Bluetooth: Add SCO fallback for eSCO connection attempts
When attempting to setup eSCO connections it can happen that some link
manager implementations fail to properly negotiate the eSCO parameters
and thus fail the eSCO setup. Normally the link manager is responsible
for the negotiation of the parameters and actually fallback to SCO if
no agreement can be reached. In cases where the link manager is just too
stupid, then at least try to establish a SCO link if eSCO fails.

For the Bluetooth devices with EDR support this includes handling packet
types of EDR basebands. This is particular tricky since for the EDR the
logic of enabling/disabling one specific packet type is turned around.
This fix contains an extra bitmask to disable eSCO EDR packet when
trying to fallback to a SCO connection.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:37 +01:00
Marcel Holtmann
255c76014a Bluetooth: Don't check encryption for L2CAP raw sockets
For L2CAP sockets with medium and high security requirement a missing
encryption will enforce the closing of the link. For the L2CAP raw
sockets this is not needed, so skip that check.

This fixes a crash when pairing Bluetooth 2.0 (and earlier) devices
since the L2CAP state machine got confused and then locked up the whole
system.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:36 +01:00
Jaikumar Ganesh
6e1031a400 Bluetooth: When encryption is dropped, do not send RFCOMM packets
During a role change with pre-Bluetooth 2.1 devices, the remote side drops
the encryption of the RFCOMM connection. We allow a grace period for the
encryption to be re-established, before dropping the connection. During
this grace period, the RFCOMM_SEC_PENDING flag is set. Check this flag
before sending RFCOMM packets.

Signed-off-by: Jaikumar Ganesh <jaikumar@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:35 +01:00
Dave Young
dd2efd03b4 Bluetooth: Remove CONFIG_DEBUG_LOCK_ALLOC ifdefs
Due to lockdep changes, the CONFIG_DEBUG_LOCK_ALLOC ifdef is not needed
now. So just remove it here.

The following commit fixed the !lockdep build warnings:

commit e8f6fbf62d
Author: Ingo Molnar <mingo@elte.hu>
Date:   Wed Nov 12 01:38:36 2008 +0000

    lockdep: include/linux/lockdep.h - fix warning in net/bluetooth/af_bluetooth.c

Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:34 +01:00
Marcel Holtmann
5f9018af00 Bluetooth: Update version numbers
With the support for the enhanced security model and the support for
deferring connection setup, it is a good idea to increase various
version numbers.

This is purely cosmetic and has no effect on the behavior, but can
be really helpful when debugging problems in different kernel versions.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:34 +01:00
Marcel Holtmann
0588d94fd7 Bluetooth: Restrict application of socket options
The new socket options should only be evaluated for SOL_BLUETOOTH level
and not for every other level. Previously this causes some minor issues
when detecting if a kernel with certain features is available.

Also restrict BT_SECURITY to SOCK_SEQPACKET for L2CAP and SOCK_STREAM for
the RFCOMM protocol.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:33 +01:00
Marcel Holtmann
f62e4323ab Bluetooth: Disconnect L2CAP connections without encryption
For L2CAP connections with high security setting, the link will be
immediately dropped when the encryption gets disabled. For L2CAP
connections with medium security there will be grace period where
the remote device has the chance to re-enable encryption. If it
doesn't happen then the link will also be disconnected.

The requirement for the grace period with medium security comes from
Bluetooth 2.0 and earlier devices that require role switching.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:33 +01:00
Marcel Holtmann
8c84b83076 Bluetooth: Pause RFCOMM TX when encryption drops
A role switch with devices following the Bluetooth pre-2.1 standards
or without Encryption Pause and Resume support is not possible if
encryption is enabled. Most newer headsets require the role switch,
but also require that the connection is encrypted.

For connections with a high security mode setting, the link will be
immediately dropped. When the connection uses medium security mode
setting, then a grace period is introduced where the TX is halted and
the remote device gets a change to re-enable encryption after the
role switch. If not re-enabled the link will be dropped.

Based on initial work by Ville Tervo <ville.tervo@nokia.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:33 +01:00