kernel.git/net/bluetooth/rfcomm/core.c, branch linux-2.6.25.y

bluetooth: fix locking bug in the rfcomm socket cleanup handling

2008-06-16T20:19:53Z

[ Upstream commit: 7dccf1f4e1696c79bff064c3770867cc53cbc71c ] 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 Signed-off-by: Chris Wright

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

remove final fastcall users

2008-02-14T00:21:18Z

fastcall always expands to empty, remove it. Signed-off-by: Harvey Harrison Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[NET]: Convert init_timer into setup_timer

2008-01-28T22:53:35Z

Many-many code in the kernel initialized the timer->function and timer->data together with calling init_timer(timer). There is already a helper for this. Use it for networking code. The patch is HUGE, but makes the code 130 lines shorter (98 insertions(+), 228 deletions(-)). Signed-off-by: Pavel Emelyanov Acked-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller

[Bluetooth] Convert RFCOMM to use kthread API

2007-10-22T09:59:49Z

This patch does the full kthread conversion for the RFCOMM protocol. It makes the code slightly simpler and more maintainable. Based on a patch from Christoph Hellwig Signed-off-by: Marcel Holtmann

Freezer: make kernel threads nonfreezable by default

2007-07-17T17:23:02Z

Currently, the freezer treats all tasks as freezable, except for the kernel threads that explicitly set the PF_NOFREEZE flag for themselves. This approach is problematic, since it requires every kernel thread to either set PF_NOFREEZE explicitly, or call try_to_freeze(), even if it doesn't care for the freezing of tasks at all. It seems better to only require the kernel threads that want to or need to be frozen to use some freezer-related code and to remove any freezer-related code from the other (nonfreezable) kernel threads, which is done in this patch. The patch causes all kernel threads to be nonfreezable by default (ie. to have PF_NOFREEZE set by default) and introduces the set_freezable() function that should be called by the freezable kernel threads in order to unset PF_NOFREEZE. It also makes all of the currently freezable kernel threads call set_freezable(), so it shouldn't cause any (intentional) change of behaviour to appear. Additionally, it updates documentation to describe the freezing of tasks more accurately. [akpm@linux-foundation.org: build fixes] Signed-off-by: Rafael J. Wysocki Acked-by: Nigel Cunningham Cc: Pavel Machek Cc: Oleg Nesterov Cc: Gautham R Shenoy Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[Bluetooth] Disconnect L2CAP connection after last RFCOMM DLC

2007-05-04T22:36:13Z

The RFCOMM specification says that the device closing the last DLC on a particular session is responsible for closing the multiplexer by closing the corresponding L2CAP channel. Signed-off-by: Ville Tervo Signed-off-by: Marcel Holtmann

[Bluetooth] Use in-kernel sockets API

2007-05-04T22:36:06Z

The kernel provides a new convenient way to access the sockets API for in-kernel users. It is a good idea to actually use it. Signed-off-by: Marcel Holtmann

[BLUETOOTH] rfcomm_worker(): fix wakeup race

2007-04-26T08:41:01Z

Set TASK_INTERRUPTIBLE prior to testing the flag to avoid missed wakeups. Signed-off-by: Andrew Morton Acked-by: Marcel Holtmann Signed-off-by: David S. Miller

[SK_BUFF]: Convert skb->tail to sk_buff_data_t

2007-04-26T05:26:28Z

So that it is also an offset from skb->head, reduces its size from 8 to 4 bytes on 64bit architectures, allowing us to combine the 4 bytes hole left by the layer headers conversion, reducing struct sk_buff size to 256 bytes, i.e. 4 64byte cachelines, and since the sk_buff slab cache is SLAB_HWCACHE_ALIGN... :-) Many calculations that previously required that skb->{transport,network, mac}_header be first converted to a pointer now can be done directly, being meaningful as offsets or pointers. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller