linux-toradex.git/net/bluetooth, branch v2.6.30.2

Bluetooth: Remove useless flush_work() causing lockdep warnings

2009-05-27T07:15:57+00:00

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: [] flush_work+0x28/0xb0

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

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

stack backtrace:
Pid: 2518, comm: bluetooth Not tainted 2.6.30-rc6-02911-gbb803cf #16
Call Trace:
 [] ? printk+0xf/0x11
 [] __lock_acquire+0x7ce/0xb1b
 [] lock_acquire+0x90/0xad
 [] ? flush_work+0x28/0xb0
 [] flush_work+0x42/0xb0
 [] ? flush_work+0x28/0xb0
 [] del_conn+0x1c/0x84 [bluetooth]
 [] worker_thread+0x18e/0x25e
 [] ? worker_thread+0x149/0x25e
 [] ? del_conn+0x0/0x84 [bluetooth]
 [] ? autoremove_wake_function+0x0/0x33
 [] ? worker_thread+0x0/0x25e
 [] kthread+0x45/0x6b
 [] ? kthread+0x0/0x6b
 [] kernel_thread_helper+0x7/0x10

Based on a report by Oliver Hartkopp 

Signed-off-by: Dave Young 
Tested-by: Oliver Hartkopp 
Signed-off-by: Marcel Holtmann

Bluetooth: Don't trigger disconnect timeout for security mode 3 pairing

2009-05-10T01:09:52+00:00

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 

Signed-off-by: Marcel Holtmann 
Tested-by: Johan Hedberg

Bluetooth: Don't use hci_acl_connect_cancel() for incoming connections

2009-05-10T01:09:45+00:00

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 

Signed-off-by: Marcel Holtmann 
Tested-by: Johan Hedberg

Bluetooth: Fix wrong module refcount when connection setup fails

2009-05-10T01:09:38+00:00

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     -> 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 

Signed-off-by: Marcel Holtmann 
Tested-by: Bing Zhao

Bluetooth: Move dev_set_name() to a context that can sleep

2009-05-05T20:26:08+00:00

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: [] hci_rx_task+0x2f/0x2d0 [bluetooth]
[  110.012173]  #1:  (&hdev->lock){+.-.+.}, at: [] 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]    [] __might_sleep+0x14d/0x170
[  110.012228]  [] __kmalloc+0x111/0x170
[  110.012239]  [] kvasprintf+0x64/0xb0
[  110.012248]  [] kobject_set_name_vargs+0x3b/0xa0
[  110.012257]  [] dev_set_name+0x76/0xa0
[  110.012273]  [] ? hci_event_packet+0x72/0x25c0 [bluetooth]
[  110.012289]  [] hci_conn_add_sysfs+0x3d/0x70 [bluetooth]
[  110.012303]  [] hci_event_packet+0xbc/0x25c0 [bluetooth]
[  110.012312]  [] ? sock_def_readable+0x80/0xa0
[  110.012328]  [] ? hci_send_to_sock+0xfc/0x1c0 [bluetooth]
[  110.012343]  [] ? sock_def_readable+0x80/0xa0
[  110.012347]  [] ? _read_unlock+0x75/0x80
[  110.012354]  [] ? hci_send_to_sock+0xfc/0x1c0 [bluetooth]
[  110.012360]  [] hci_rx_task+0x203/0x2d0 [bluetooth]
[  110.012365]  [] tasklet_action+0xb5/0x160
[  110.012369]  [] __do_softirq+0x9c/0x150
[  110.012372]  [] ? _spin_unlock+0x3f/0x80
[  110.012376]  [] call_softirq+0x1c/0x30
[  110.012380]  [] do_softirq+0x8d/0xe0
[  110.012383]  [] irq_exit+0xc5/0xe0
[  110.012386]  [] do_IRQ+0x9d/0x120
[  110.012389]  [] ret_from_intr+0x0/0xf
[  110.012391]    [] ? acpi_idle_enter_bm+0x264/0x2a6
[  110.012399]  [] ? acpi_idle_enter_bm+0x25a/0x2a6
[  110.012403]  [] ? cpuidle_idle_call+0xc5/0x130
[  110.012407]  [] ? cpu_idle+0xc4/0x130
[  110.012411]  [] ? rest_init+0x88/0xb0
[  110.012416]  [] ? start_kernel+0x3b5/0x412
[  110.012420]  [] ? x86_64_start_reservations+0x91/0xb5
[  110.012424]  [] ? x86_64_start_kernel+0xef/0x11b

Based on a report by Davide Pesavento 

Signed-off-by: Marcel Holtmann 
Tested-by: Hugo Mildenberger 
Tested-by: Bing Zhao

Bluetooth: Fix issue with sysfs handling for connections

2009-05-04T21:29:02+00:00

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 

Signed-off-by: Marcel Holtmann 
Tested-by: Justin P. Mattock 
Tested-by: Roger Quadros 
Tested-by: Marc Pignat

Bluetooth: Fix connection establishment with low security requirement

2009-04-28T16:31:39+00:00

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 

Signed-off-by: Marcel Holtmann

Bluetooth: Add different pairing timeout for Legacy Pairing

2009-04-28T16:31:38+00:00

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 

Signed-off-by: Marcel Holtmann

Bluetooth: Ensure that HCI sysfs add/del is preempt safe

2009-04-28T16:31:38+00:00

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 : []    lr : []    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 
Signed-off-by: Marcel Holtmann

Bluetooth: Add workaround for wrong HCI event in eSCO setup

2009-04-19T17:30:03+00:00

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 

Signed-off-by: Marcel Holtman