linux-stable.git/net/bluetooth, branch linux-2.6.25.y

Bluetooth: Signal user-space for HIDP and BNEP socket errors

2008-08-06T17:11:02+00:00

commit ec8dab36e0738d3059980d144e34f16a26bbda7d upstream

When using the HIDP or BNEP kernel support, the user-space needs to
know if the connection has been terminated for some reasons. Wake up
the application if that happens. Otherwise kernel and user-space are
no longer on the same page and weird behaviors can happen.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

bluetooth: rfcomm_dev_state_change deadlock fix

2008-06-16T20:19:54+00:00

commit 537d59af73d894750cff14f90fe2b6d77fbab15b in mainline

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 
Signed-off-by: Greg Kroah-Hartman

bluetooth: fix locking bug in the rfcomm socket cleanup handling

2008-06-16T20:19:53+00:00

[ 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:06+00:00

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:35+00:00

'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:38+00:00

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

bluetooth: make bnep_sock_cleanup() return void

2008-03-06T02:47:40+00:00

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:03+00:00

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

bluetooth: hci_core: defer hci_unregister_sysfs()

2008-03-06T02:45:59+00:00

Alon Bar-Lev reports:

 Feb 16 23:41:33 alon1 usb 3-1: configuration #1 chosen from 1 choice
Feb 16 23:41:33 alon1 BUG: unable to handle kernel NULL pointer  
dereference at virtual address 00000008
Feb 16 23:41:33 alon1 printing eip: c01b2db6 *pde = 00000000
Feb 16 23:41:33 alon1 Oops: 0000 [#1] PREEMPT
Feb 16 23:41:33 alon1 Modules linked in: ppp_deflate zlib_deflate  
zlib_inflate bsd_comp ppp_async rfcomm l2cap hci_usb vmnet(P)  
vmmon(P) tun radeon drm autofs4 ipv6 aes_generic crypto_algapi  
ieee80211_crypt_ccmp nf_nat_irc nf_nat_ftp nf_conntrack_irc  
nf_conntrack_ftp ipt_MASQUERADE iptable_nat nf_nat ipt_REJECT  
xt_tcpudp ipt_LOG xt_limit xt_state nf_conntrack_ipv4 nf_conntrack  
iptable_filter ip_tables x_tables snd_pcm_oss snd_mixer_oss  
snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device  
bluetooth ppp_generic slhc ioatdma dca cfq_iosched cpufreq_powersave  
cpufreq_ondemand cpufreq_conservative acpi_cpufreq freq_table uinput  
fan af_packet nls_cp1255 nls_iso8859_1 nls_utf8 nls_base pcmcia  
snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm nsc_ircc snd_timer  
ipw2200 thinkpad_acpi irda snd ehci_hcd yenta_socket uhci_hcd  
psmouse ieee80211 soundcore intel_agp hwmon rsrc_nonstatic pcspkr  
e1000 crc_ccitt snd_page_alloc i2c_i801 ieee80211_crypt pcmcia_core  
agpgart thermal bat!
tery nvram rtc sr_mod ac sg firmware_class button processor cdrom  
unix usbcore evdev ext3 jbd ext2 mbcache loop ata_piix libata sd_mod  
scsi_mod
Feb 16 23:41:33 alon1
Feb 16 23:41:33 alon1 Pid: 4, comm: events/0 Tainted: P         
(2.6.24-gentoo-r2 #1)
Feb 16 23:41:33 alon1 EIP: 0060:[] EFLAGS: 00010282 CPU: 0
Feb 16 23:41:33 alon1 EIP is at sysfs_get_dentry+0x26/0x80
Feb 16 23:41:33 alon1 EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX:  
f48a2210
Feb 16 23:41:33 alon1 ESI: f72eb900 EDI: f4803ae0 EBP: f4803ae0 ESP:  
f7c49efc
Feb 16 23:41:33 alon1 hcid[7004]: HCI dev 0 registered
Feb 16 23:41:33 alon1 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
Feb 16 23:41:33 alon1 Process events/0 (pid: 4, ti=f7c48000  
task=f7c3efc0 task.ti=f7c48000)
Feb 16 23:41:33 alon1 Stack: f7cb6140 f4822668 f7e71e10 c01b304d  
ffffffff ffffffff fffffffe c030ba9c
Feb 16 23:41:33 alon1 f7cb6140 f4822668 f6da6720 f7cb6140 f4822668  
f6da6720 c030ba8e c01ce20b
Feb 16 23:41:33 alon1 f6e9dd00 c030ba8e f6da6720 f6e9dd00 f6e9dd00  
00000000 f4822600 00000000
Feb 16 23:41:33 alon1 Call Trace:
Feb 16 23:41:33 alon1 [] sysfs_move_dir+0x3d/0x1f0
Feb 16 23:41:33 alon1 [] kobject_move+0x9b/0x120
Feb 16 23:41:33 alon1 [] device_move+0x51/0x110
Feb 16 23:41:33 alon1 [] del_conn+0x0/0x70 [bluetooth]
Feb 16 23:41:33 alon1 [] del_conn+0x19/0x70 [bluetooth]
Feb 16 23:41:33 alon1 [] run_workqueue+0x81/0x140
Feb 16 23:41:33 alon1 [] schedule+0x168/0x2e0
Feb 16 23:41:33 alon1 [] autoremove_wake_function+0x0/0x50
Feb 16 23:41:33 alon1 [] worker_thread+0x9b/0xf0
Feb 16 23:41:33 alon1 [] autoremove_wake_function+0x0/0x50
Feb 16 23:41:33 alon1 [] worker_thread+0x0/0xf0
Feb 16 23:41:33 alon1 [] kthread+0x42/0x70
Feb 16 23:41:33 alon1 [] kthread+0x0/0x70
Feb 16 23:41:33 alon1 [] kernel_thread_helper+0x7/0x18
Feb 16 23:41:33 alon1 =======================
Feb 16 23:41:33 alon1 Code: 26 00 00 00 00 57 89 c7 a1 50 1b 3a c0  
56 53 8b 70 38 85 f6 74 08 8b 0e 85 c9 74 58 ff 06 8b 56 50 39 fa 74  
47 89 fb eb 02 89 c3 <8b> 43 08 39 c2 75 f7 8b 46 08 83 c0 68 e8 98  
e7 10 00 8b 43 10
Feb 16 23:41:33 alon1 EIP: [] sysfs_get_dentry+0x26/0x80  
SS:ESP 0068:f7c49efc
Feb 16 23:41:33 alon1 ---[ end trace aae864e9592acc1d ]---

Defer hci_unregister_sysfs because hci device could be destructed
while hci conn devices still there.

Signed-off-by: Dave Young 
Tested-by: Stefan Seyfried 
Acked-by: Alon Bar-Lev 
Signed-off-by: Andrew Morton 
Acked-by: Marcel Holtmann

[BLUETOOTH]: l2cap info_timer delete fix in hci_conn_del

2008-03-03T20:18:55+00:00

When the l2cap info_timer is active the info_state will be set to
L2CAP_INFO_FEAT_MASK_REQ_SENT, and it will be unset after the timer is
deleted or timeout triggered.

Here in l2cap_conn_del only call del_timer_sync when the info_state is
set to L2CAP_INFO_FEAT_MASK_REQ_SENT.

Signed-off-by: Dave Young 
Acked-by: Marcel Holtmann 
Signed-off-by: David S. Miller