linux/net/bluetooth, branch v2.6.26

bluetooth: rfcomm_dev_state_change deadlock fix

2008-06-03T21:27:17Z

There's logic in __rfcomm_dlc_close: rfcomm_dlc_lock(d); d->state = BT_CLOSED; d->state_changed(d, err); rfcomm_dlc_unlock(d); In rfcomm_dev_state_change, it's possible that rfcomm_dev_put try to take the dlc lock, then we will deadlock. Here fixed it by unlock dlc before rfcomm_dev_get in rfcomm_dev_state_change. why not unlock just before rfcomm_dev_put? it's because there's another problem. rfcomm_dev_get/rfcomm_dev_del will take rfcomm_dev_lock, but in rfcomm_dev_add the lock order is : rfcomm_dev_lock --> dlc lock so I unlock dlc before the taken of rfcomm_dev_lock. Actually it's a regression caused by commit 1905f6c736cb618e07eca0c96e60e3c024023428 ("bluetooth : __rfcomm_dlc_close lock fix"), the dlc state_change could be two callbacks : rfcomm_sk_state_change and rfcomm_dev_state_change. I missed the rfcomm_sk_state_change that time. Thanks Arjan van de Ven for the effort in commit 4c8411f8c115def968820a4df6658ccfd55d7f1a ("bluetooth: fix locking bug in the rfcomm socket cleanup handling") but he missed the rfcomm_dev_state_change lock issue. Signed-off-by: Dave Young Acked-by: Marcel Holtmann Signed-off-by: David S. Miller

bluetooth: fix locking bug in the rfcomm socket cleanup handling

2008-05-29T08:32:47Z

in net/bluetooth/rfcomm/sock.c, rfcomm_sk_state_change() does the following operation: if (parent && sock_flag(sk, SOCK_ZAPPED)) { /* We have to drop DLC lock here, otherwise * rfcomm_sock_destruct() will dead lock. */ rfcomm_dlc_unlock(d); rfcomm_sock_kill(sk); rfcomm_dlc_lock(d); } } which is fine, since rfcomm_sock_kill() will call sk_free() which will call rfcomm_sock_destruct() which takes the rfcomm_dlc_lock()... so far so good. HOWEVER, this assumes that the rfcomm_sk_state_change() function always gets called with the rfcomm_dlc_lock() taken. This is the case for all but one case, and in that case where we don't have the lock, we do a double unlock followed by an attempt to take the lock, which due to underflow isn't going anywhere fast. This patch fixes this by moving the stragling case inside the lock, like the other usages of the same call are doing in this code. This was found with the help of the www.kerneloops.org project, where this deadlock was observed 51 times at this point in time: http://www.kerneloops.org/search.php?search=rfcomm_sock_destruct Signed-off-by: Arjan van de Ven Acked-by: Marcel Holtmann Signed-off-by: David S. Miller

bluetooth: use get/put_unaligned_* helpers

2008-05-02T23:25:46Z

Signed-off-by: Harvey Harrison Acked-by: Marcel Holtmann Signed-off-by: David S. Miller

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6

2008-04-03T05:35:23Z

Conflicts: drivers/net/s2io.c

bluetooth : __rfcomm_dlc_close lock fix

2008-04-02T06:59:06Z

Lockdep warning will be trigged while rfcomm connection closing. The locks taken in rfcomm_dev_add: rfcomm_dev_lock --> d->lock In __rfcomm_dlc_close: d->lock --> rfcomm_dev_lock (in rfcomm_dev_state_change) There's two way to fix it, one is in rfcomm_dev_add we first locking d->lock then the rfcomm_dev_lock The other (in this patch), remove the locking of d->lock for rfcomm_dev_state_change because just locking "d->state = BT_CLOSED;" is enough. [ 295.002046] ======================================================= [ 295.002046] [ INFO: possible circular locking dependency detected ] [ 295.002046] 2.6.25-rc7 #1 [ 295.002046] ------------------------------------------------------- [ 295.002046] krfcommd/2705 is trying to acquire lock: [ 295.002046] (rfcomm_dev_lock){-.--}, at: [] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [ 295.002046] but task is already holding lock: [ 295.002046] (&d->lock){--..}, at: [] __rfcomm_dlc_close+0x43/0xd0 [rfcomm] [ 295.002046] [ 295.002046] which lock already depends on the new lock. [ 295.002046] [ 295.002046] [ 295.002046] the existing dependency chain (in reverse order) is: [ 295.002046] [ 295.002046] -> #1 (&d->lock){--..}: [ 295.002046] [] check_prev_add+0xd3/0x200 [ 295.002046] [] check_prevs_add+0x95/0xe0 [ 295.002046] [] validate_chain+0x23f/0x320 [ 295.002046] [] __lock_acquire+0x1c1/0x760 [ 295.002046] [] lock_acquire+0x79/0xb0 [ 295.002046] [] _spin_lock+0x39/0x80 [ 295.002046] [] rfcomm_dev_add+0x240/0x360 [rfcomm] [ 295.002046] [] rfcomm_create_dev+0x6e/0xe0 [rfcomm] [ 295.002046] [] rfcomm_dev_ioctl+0x33/0x60 [rfcomm] [ 295.002046] [] rfcomm_sock_ioctl+0x2c/0x50 [rfcomm] [ 295.002046] [] sock_ioctl+0x118/0x240 [ 295.002046] [] vfs_ioctl+0x76/0x90 [ 295.002046] [] do_vfs_ioctl+0x56/0x140 [ 295.002046] [] sys_ioctl+0x39/0x60 [ 295.002046] [] syscall_call+0x7/0xb [ 295.002046] [] 0xffffffff [ 295.002046] [ 295.002046] -> #0 (rfcomm_dev_lock){-.--}: [ 295.002046] [] check_prev_add+0x34/0x200 [ 295.002046] [] check_prevs_add+0x95/0xe0 [ 295.002046] [] validate_chain+0x23f/0x320 [ 295.002046] [] __lock_acquire+0x1c1/0x760 [ 295.002046] [] lock_acquire+0x79/0xb0 [ 295.002046] [] _read_lock+0x39/0x80 [ 295.002046] [] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [] __rfcomm_dlc_close+0x58/0xd0 [rfcomm] [ 295.002046] [] rfcomm_recv_ua+0x6f/0x120 [rfcomm] [ 295.002046] [] rfcomm_recv_frame+0x171/0x1e0 [rfcomm] [ 295.002046] [] rfcomm_run+0xe7/0x550 [rfcomm] [ 295.002046] [] kthread+0x5c/0xa0 [ 295.002046] [] kernel_thread_helper+0x7/0x10 [ 295.002046] [] 0xffffffff [ 295.002046] [ 295.002046] other info that might help us debug this: [ 295.002046] [ 295.002046] 2 locks held by krfcommd/2705: [ 295.002046] #0: (rfcomm_mutex){--..}, at: [] rfcomm_run+0x7b/0x550 [rfcomm] [ 295.002046] #1: (&d->lock){--..}, at: [] __rfcomm_dlc_close+0x43/0xd0 [rfcomm] [ 295.002046] [ 295.002046] stack backtrace: [ 295.002046] Pid: 2705, comm: krfcommd Not tainted 2.6.25-rc7 #1 [ 295.002046] [] ? printk+0x18/0x20 [ 295.002046] [] print_circular_bug_tail+0x6f/0x80 [ 295.002046] [] check_prev_add+0x34/0x200 [ 295.002046] [] check_prevs_add+0x95/0xe0 [ 295.002046] [] validate_chain+0x23f/0x320 [ 295.002046] [] __lock_acquire+0x1c1/0x760 [ 295.002046] [] lock_acquire+0x79/0xb0 [ 295.002046] [] ? rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [] _read_lock+0x39/0x80 [ 295.002046] [] ? rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [] __rfcomm_dlc_close+0x58/0xd0 [rfcomm] [ 295.002046] [] rfcomm_recv_ua+0x6f/0x120 [rfcomm] [ 295.002046] [] rfcomm_recv_frame+0x171/0x1e0 [rfcomm] [ 295.002046] [] ? trace_hardirqs_on+0xb9/0x130 [ 295.002046] [] ? _spin_unlock_irqrestore+0x39/0x70 [ 295.002046] [] rfcomm_run+0xe7/0x550 [rfcomm] [ 295.002046] [] ? __sched_text_start+0x229/0x4c0 [ 295.002046] [] ? cpu_avg_load_per_task+0x20/0x30 [ 295.002046] [] ? rfcomm_run+0x0/0x550 [rfcomm] [ 295.002046] [] kthread+0x5c/0xa0 [ 295.002046] [] ? kthread+0x0/0xa0 [ 295.002046] [] kernel_thread_helper+0x7/0x10 [ 295.002046] ======================= Signed-off-by: Dave Young Signed-off-by: David S. Miller

bluetooth : use lockdep sub-classes for diffrent bluetooth protocol

2008-04-02T06:58:35Z

'rfcomm connect' will trigger lockdep warnings which is caused by locking diffrent kinds of bluetooth sockets at the same time. So using sub-classes per AF_BLUETOOTH sub-type for lockdep. Thanks for the hints from dave jones. --- > From: Dave Jones > Date: Thu, 27 Mar 2008 12:21:56 -0400 > > > Mar 27 08:10:57 localhost kernel: Pid: 3611, comm: obex-data-serve Not tainted 2.6.25-0.121.rc5.git4.fc9 #1 > > Mar 27 08:10:57 localhost kernel: [__lock_acquire+2287/3089] __lock_acquire+0x8ef/0xc11 > > Mar 27 08:10:57 localhost kernel: [sched_clock+8/11] ? sched_clock+0x8/0xb > > Mar 27 08:10:57 localhost kernel: [lock_acquire+106/144] lock_acquire+0x6a/0x90 > > Mar 27 08:10:57 localhost kernel: [] ? l2cap_sock_bind+0x29/0x108 [l2cap] > > Mar 27 08:10:57 localhost kernel: [lock_sock_nested+182/198] lock_sock_nested+0xb6/0xc6 > > Mar 27 08:10:57 localhost kernel: [] ? l2cap_sock_bind+0x29/0x108 [l2cap] > > Mar 27 08:10:57 localhost kernel: [security_socket_post_create+22/27] ? security_socket_post_create+0x16/0x1b > > Mar 27 08:10:57 localhost kernel: [__sock_create+388/472] ? __sock_create+0x184/0x1d8 > > Mar 27 08:10:57 localhost kernel: [] l2cap_sock_bind+0x29/0x108 [l2cap] > > Mar 27 08:10:57 localhost kernel: [kernel_bind+10/13] kernel_bind+0xa/0xd > > Mar 27 08:10:57 localhost kernel: [] rfcomm_dlc_open+0xc8/0x294 [rfcomm] > > Mar 27 08:10:57 localhost kernel: [lock_sock_nested+187/198] ? lock_sock_nested+0xbb/0xc6 > > Mar 27 08:10:57 localhost kernel: [] rfcomm_sock_connect+0x8b/0xc2 [rfcomm] > > Mar 27 08:10:57 localhost kernel: [sys_connect+96/125] sys_connect+0x60/0x7d > > Mar 27 08:10:57 localhost kernel: [__lock_acquire+1370/3089] ? __lock_acquire+0x55a/0xc11 > > Mar 27 08:10:57 localhost kernel: [sys_socketcall+140/392] sys_socketcall+0x8c/0x188 > > Mar 27 08:10:57 localhost kernel: [syscall_call+7/11] syscall_call+0x7/0xb --- Signed-off-by: Dave Young Signed-off-by: David S. Miller

bluetooth: replace deprecated RW_LOCK_UNLOCKED macros

2008-03-28T23:17:38Z

The older RW_LOCK_UNLOCKED macros defeat lockdep state tracing so replace them with the newer __RW_LOCK_UNLOCKED macros. Signed-off-by: Robert P. J. Day Acked-by: Marcel Holtmann Signed-off-by: Andrew Morton Signed-off-by: David S. Miller

[NET] NETNS: Omit sock->sk_net without CONFIG_NET_NS.

2008-03-25T19:39:55Z

Introduce per-sock inlines: sock_net(), sock_net_set() and per-inet_timewait_sock inlines: twsk_net(), twsk_net_set(). Without CONFIG_NET_NS, no namespace other than &init_net exists. Let's explicitly define them to help compiler optimizations. Signed-off-by: YOSHIFUJI Hideaki

bluetooth: make bnep_sock_cleanup() return void

2008-03-06T02:47:40Z

bnep_sock_cleanup() always returns 0 and its return value isn't used anywhere in the code. Signed-off-by: Tobias Klauser Signed-off-by: Andrew Morton Signed-off-by: David S. Miller

bluetooth: Make hci_sock_cleanup() return void

2008-03-06T02:47:03Z

hci_sock_cleanup() always returns 0 and its return value isn't used anywhere in the code. Compile-tested with 'make allyesconfig && make net/bluetooth/bluetooth.ko' Signed-off-by: Tobias Klauser Signed-off-by: Andrew Morton Acked-by: Marcel Holtmann