* [Regression] Bluetooth RFComm: using it locks up the machine
@ 2007-03-04 14:53 Mark Lord
2007-03-04 15:12 ` Mark Lord
0 siblings, 1 reply; 7+ messages in thread
From: Mark Lord @ 2007-03-04 14:53 UTC (permalink / raw)
To: Linux Kernel, bluez-devel, marcel, Andrew Morton
[-- Attachment #1: Type: text/plain, Size: 582 bytes --]
Any attempt to open/use a bluetooth rfcomm device locks up
scheduling completely on my machine.
Interrupts (ping, alt-sysrq) seem to be alive, but nothing else.
This was working fine in 2.6.20, broken now in 2.6.21-rc2-git*
Mar 4 09:43:52 silvy kernel: Bluetooth: L2CAP ver 2.8
Mar 4 09:43:52 silvy kernel: Bluetooth: L2CAP socket layer initialized
Mar 4 09:43:52 silvy kernel: Bluetooth: RFCOMM socket layer initialized
Mar 4 09:43:52 silvy kernel: Bluetooth: RFCOMM TTY layer initialized
Mar 4 09:43:52 silvy kernel: Bluetooth: RFCOMM ver 1.8
More info attached.
Cheers
[-- Attachment #2: lsusb_grep_bluetooth.txt --]
[-- Type: text/plain, Size: 9427 bytes --]
Bus 002 Device 002: ID 413c:8103 Dell Computer Corp. Wireless 350 Bluetooth
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x413c Dell Computer Corp.
idProduct 0x8103 Wireless 350 Bluetooth
bcdDevice 16.57
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 193
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 1x 9 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 1x 9 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 1x 17 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 1x 17 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 3
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0019 1x 25 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0019 1x 25 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 4
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0021 1x 33 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0021 1x 33 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 5
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0031 1x 49 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0031 1x 49 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 0
iInterface 0
Device Status: 0x0001
Self Powered
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [Regression] Bluetooth RFComm: using it locks up the machine 2007-03-04 14:53 [Regression] Bluetooth RFComm: using it locks up the machine Mark Lord @ 2007-03-04 15:12 ` Mark Lord 2007-03-04 17:33 ` Marcel Holtmann 2007-03-04 17:55 ` Mark Lord 0 siblings, 2 replies; 7+ messages in thread From: Mark Lord @ 2007-03-04 15:12 UTC (permalink / raw) To: Mark Lord Cc: Linux Kernel, bluez-devel, marcel, Andrew Morton, David S. Miller Mark Lord wrote: > Any attempt to open/use a bluetooth rfcomm device locks up > scheduling completely on my machine. > > Interrupts (ping, alt-sysrq) seem to be alive, but nothing else. > > This was working fine in 2.6.20, broken now in 2.6.21-rc2-git* Further info: Reverting this change (below) fixes it: | author Marcel Holtmann <marcel@holtmann.org> | Sat, 17 Feb 2007 22:58:57 +0000 (23:58 +0100) | committer David S. Miller <davem@sunset.davemloft.net> | Mon, 26 Feb 2007 19:42:41 +0000 (11:42 -0800) | commit c1a3313698895d8ad4760f98642007bf236af2e8 | tree 337a876f727061362b6a169f8759849c105b8f7a tree | snapshot | parent f5ffd4620aba9e55656483ae1ef5c79ba81f5403 commit | diff | | [Bluetooth] Make use of device_move() for RFCOMM TTY devices | | In the case of bound RFCOMM TTY devices the parent is not available | before its usage. So when opening a RFCOMM TTY device, move it to | the corresponding ACL device as a child. When closing the device, | move it back to the virtual device tree. | Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Specifically, I reverted these changes, below, to fix it: --- 2.6.20/net/bluetooth/rfcomm/tty.c 2007-02-04 13:44:54.000000000 -0500 +++ 2.6.21/net/bluetooth/rfcomm/tty.c 2007-03-02 15:06:32.000000000 -0500 @@ -74,6 +74,8 @@ wait_queue_head_t wait; struct tasklet_struct wakeup_task; + struct device *tty_dev; + atomic_t wmem_alloc; }; @@ -261,7 +263,7 @@ return err; } - tty_register_device(rfcomm_tty_driver, dev->id, rfcomm_get_device(dev)); + dev->tty_dev = tty_register_device(rfcomm_tty_driver, dev->id, NULL); return dev->id; } @@ -630,6 +632,9 @@ set_current_state(TASK_RUNNING); remove_wait_queue(&dev->wait, &wait); + if (err == 0) + device_move(dev->tty_dev, rfcomm_get_device(dev)); + return err; } @@ -642,6 +647,8 @@ BT_DBG("tty %p dev %p dlc %p opened %d", tty, dev, dev->dlc, dev->opened); if (--dev->opened == 0) { + device_move(dev->tty_dev, NULL); + /* Close DLC and dettach TTY */ rfcomm_dlc_close(dev->dlc, 0); ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Regression] Bluetooth RFComm: using it locks up the machine 2007-03-04 15:12 ` Mark Lord @ 2007-03-04 17:33 ` Marcel Holtmann 2007-03-04 17:55 ` Mark Lord 1 sibling, 0 replies; 7+ messages in thread From: Marcel Holtmann @ 2007-03-04 17:33 UTC (permalink / raw) To: Mark Lord; +Cc: Linux Kernel, bluez-devel, Andrew Morton, David S. Miller Hi Mark, > > Any attempt to open/use a bluetooth rfcomm device locks up > > scheduling completely on my machine. > > > > Interrupts (ping, alt-sysrq) seem to be alive, but nothing else. > > > > This was working fine in 2.6.20, broken now in 2.6.21-rc2-git* > > Further info: Reverting this change (below) fixes it: > > | author Marcel Holtmann <marcel@holtmann.org> > | Sat, 17 Feb 2007 22:58:57 +0000 (23:58 +0100) > | committer David S. Miller <davem@sunset.davemloft.net> > | Mon, 26 Feb 2007 19:42:41 +0000 (11:42 -0800) > | commit c1a3313698895d8ad4760f98642007bf236af2e8 > | tree 337a876f727061362b6a169f8759849c105b8f7a tree | snapshot > | parent f5ffd4620aba9e55656483ae1ef5c79ba81f5403 commit | diff > | > | [Bluetooth] Make use of device_move() for RFCOMM TTY devices > | > | In the case of bound RFCOMM TTY devices the parent is not available > | before its usage. So when opening a RFCOMM TTY device, move it to > | the corresponding ACL device as a child. When closing the device, > | move it back to the virtual device tree. > | Signed-off-by: Marcel Holtmann <marcel@holtmann.org> > > Specifically, I reverted these changes, below, to fix it: please post these information to the Linux kernel mailing list, because I think that must be an issue with the device_move() API. I tested this successfully with a Quad G5 and it was working as expected. Regards Marcel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Regression] Bluetooth RFComm: using it locks up the machine 2007-03-04 15:12 ` Mark Lord 2007-03-04 17:33 ` Marcel Holtmann @ 2007-03-04 17:55 ` Mark Lord 2007-03-04 18:26 ` [PATCH] Fix 2.6.21 rfcomm lockups (2.6.21 regression) Mark Lord 1 sibling, 1 reply; 7+ messages in thread From: Mark Lord @ 2007-03-04 17:55 UTC (permalink / raw) Cc: Linux Kernel, bluez-devel, marcel, Andrew Morton, David S. Miller, Greg KH Mark Lord wrote: > Mark Lord wrote: >> Any attempt to open/use a bluetooth rfcomm device locks up >> scheduling completely on my machine. >> >> Interrupts (ping, alt-sysrq) seem to be alive, but nothing else. >> >> This was working fine in 2.6.20, broken now in 2.6.21-rc2-git* > > Further info: Reverting this change (below) fixes it: > > | author Marcel Holtmann <marcel@holtmann.org> > | Sat, 17 Feb 2007 22:58:57 +0000 (23:58 +0100) > | committer David S. Miller <davem@sunset.davemloft.net> > | Mon, 26 Feb 2007 19:42:41 +0000 (11:42 -0800) > | commit c1a3313698895d8ad4760f98642007bf236af2e8 > | tree 337a876f727061362b6a169f8759849c105b8f7a tree | snapshot > | parent f5ffd4620aba9e55656483ae1ef5c79ba81f5403 commit | diff > | | [Bluetooth] Make use of device_move() for RFCOMM TTY devices > | | In the case of bound RFCOMM TTY devices the parent is not available > | before its usage. So when opening a RFCOMM TTY device, move it to > | the corresponding ACL device as a child. When closing the device, > | move it back to the virtual device tree. > | Signed-off-by: Marcel Holtmann <marcel@holtmann.org> .. The lockup is happening inside the call to device_move(), specifically in sysfs_move_dir() it loops here forever: ... again: mutex_lock(&old_parent_dentry->d_inode->i_mutex); if (!mutex_trylock(&new_parent_dentry->d_inode->i_mutex)) { mutex_unlock(&old_parent_dentry->d_inode->i_mutex); goto again; } ... Screen-shot (photograph) from alt-sysrq-P is here: http://rtr.ca/recent/rfcomm_pc.jpg Cheers ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] Fix 2.6.21 rfcomm lockups (2.6.21 regression) 2007-03-04 17:55 ` Mark Lord @ 2007-03-04 18:26 ` Mark Lord 2007-03-05 12:41 ` Cornelia Huck 2007-03-05 15:33 ` Jiri Kosina 0 siblings, 2 replies; 7+ messages in thread From: Mark Lord @ 2007-03-04 18:26 UTC (permalink / raw) To: Greg KH; +Cc: Linux Kernel, bluez-devel, marcel, Andrew Morton, David S. Miller Mark Lord wrote: > Any attempt to open/use a bluetooth rfcomm device locks up > scheduling completely on my machine. > > Interrupts (ping, alt-sysrq) seem to be alive, but nothing else. > > This was working fine in 2.6.20, broken now in 2.6.21-rc2-git* Further info: Reverting this change (below) fixes it: | author Marcel Holtmann <marcel@holtmann.org> | Sat, 17 Feb 2007 22:58:57 +0000 (23:58 +0100) | committer David S. Miller <davem@sunset.davemloft.net> | Mon, 26 Feb 2007 19:42:41 +0000 (11:42 -0800) | commit c1a3313698895d8ad4760f98642007bf236af2e8 | tree 337a876f727061362b6a169f8759849c105b8f7a tree | snapshot | parent f5ffd4620aba9e55656483ae1ef5c79ba81f5403 commit | diff | | [Bluetooth] Make use of device_move() for RFCOMM TTY devices | | In the case of bound RFCOMM TTY devices the parent is not available | before its usage. So when opening a RFCOMM TTY device, move it to | the corresponding ACL device as a child. When closing the device, | move it back to the virtual device tree. | Signed-off-by: Marcel Holtmann <marcel@holtmann.org> The simplest fix for this bug is to prevent sysfs_move_dir() from self-deadlocking when (old_parent == new_parent). This patch prevents total system lockup when using rfcomm devices. Signed-off-by: Mark Lord <mlord@pobox.com> --- --- 2.6.21/fs/sysfs/dir.c 2007-03-04 13:19:00.000000000 -0500 +++ linux/fs/sysfs/dir.c 2007-03-04 13:20:45.000000000 -0500 @@ -431,6 +431,8 @@ new_parent_dentry = new_parent ? new_parent->dentry : sysfs_mount->mnt_sb->s_root; + if (old_parent_dentry->d_inode == new_parent_dentry->d_inode) + return 0; /* nothing to move */ again: mutex_lock(&old_parent_dentry->d_inode->i_mutex); if (!mutex_trylock(&new_parent_dentry->d_inode->i_mutex)) { ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Fix 2.6.21 rfcomm lockups (2.6.21 regression) 2007-03-04 18:26 ` [PATCH] Fix 2.6.21 rfcomm lockups (2.6.21 regression) Mark Lord @ 2007-03-05 12:41 ` Cornelia Huck 2007-03-05 15:33 ` Jiri Kosina 1 sibling, 0 replies; 7+ messages in thread From: Cornelia Huck @ 2007-03-05 12:41 UTC (permalink / raw) To: Mark Lord Cc: Greg KH, Linux Kernel, bluez-devel, marcel, Andrew Morton, David S. Miller On Sun, 04 Mar 2007 13:26:49 -0500, Mark Lord <lkml@rtr.ca> wrote: > The simplest fix for this bug is to prevent sysfs_move_dir() > from self-deadlocking when (old_parent == new_parent). > > This patch prevents total system lockup when using rfcomm devices. > > Signed-off-by: Mark Lord <mlord@pobox.com> > --- > --- 2.6.21/fs/sysfs/dir.c 2007-03-04 13:19:00.000000000 -0500 > +++ linux/fs/sysfs/dir.c 2007-03-04 13:20:45.000000000 -0500 > @@ -431,6 +431,8 @@ > new_parent_dentry = new_parent ? > new_parent->dentry : sysfs_mount->mnt_sb->s_root; > > + if (old_parent_dentry->d_inode == new_parent_dentry->d_inode) > + return 0; /* nothing to move */ > again: > mutex_lock(&old_parent_dentry->d_inode->i_mutex); > if (!mutex_trylock(&new_parent_dentry->d_inode->i_mutex)) { Hm, never thought that someone might call the moving functions with old_parent == new_parent, sorry about that. It should be safe to return success here, we add only a bit of overhead with some driver model juggling and emitting a not needed uevent. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Fix 2.6.21 rfcomm lockups (2.6.21 regression) 2007-03-04 18:26 ` [PATCH] Fix 2.6.21 rfcomm lockups (2.6.21 regression) Mark Lord 2007-03-05 12:41 ` Cornelia Huck @ 2007-03-05 15:33 ` Jiri Kosina 1 sibling, 0 replies; 7+ messages in thread From: Jiri Kosina @ 2007-03-05 15:33 UTC (permalink / raw) To: Mark Lord Cc: Greg KH, Linux Kernel, bluez-devel, marcel, Andrew Morton, David S. Miller On Sun, 4 Mar 2007, Mark Lord wrote: > This patch prevents total system lockup when using rfcomm devices. I acknowledge that this patch fixes lockup for me too. When debugging this, I also came across a different bug (spotted by lockdep). Is the patch below applicable? From: Jiri Kosina <jkosina@suse.cz> [Bluetooth] Fix socket locking in hci_sock_dev_event() hci_sock_dev_event() uses bh_lock_sock() to lock the socket lock. This is not deadlock-safe against locking of the same socket lock in l2cap_connect_cfm() from softirq context. In addition to that, hci_sock_dev_event() doesn't seem to be called from softirq context, so it is safe to use lock_sock()/release_sock() instead. The lockdep warning can be triggered on my T42p simply by switching the Bluetooth off by the keyboard button. ================================= [ INFO: inconsistent lock state ] 2.6.21-rc2 #4 --------------------------------- inconsistent {in-softirq-W} -> {softirq-on-W} usage. khubd/156 [HC0[0]:SC0[0]:HE1:SE1] takes: (slock-AF_BLUETOOTH){-+..}, at: [<e0ca5520>] hci_sock_dev_event+0xa8/0xc5 [bluetooth] {in-softirq-W} state was registered at: [<c012d1db>] mark_lock+0x59/0x414 [<e0cef688>] l2cap_connect_cfm+0x4e/0x11f [l2cap] [<c012dfd7>] __lock_acquire+0x3e5/0xb99 [<e0cef688>] l2cap_connect_cfm+0x4e/0x11f [l2cap] [<c012e7f2>] lock_acquire+0x67/0x81 [<e0cef688>] l2cap_connect_cfm+0x4e/0x11f [l2cap] [<c036ee72>] _spin_lock+0x29/0x34 [<e0cef688>] l2cap_connect_cfm+0x4e/0x11f [l2cap] [<e0cef688>] l2cap_connect_cfm+0x4e/0x11f [l2cap] [<e0ca17c3>] hci_send_cmd+0x126/0x14f [bluetooth] [<e0ca4ce4>] hci_event_packet+0x729/0xebd [bluetooth] [<e0ca205b>] hci_rx_task+0x2a/0x20f [bluetooth] [<e0ca209d>] hci_rx_task+0x6c/0x20f [bluetooth] [<c012d7be>] trace_hardirqs_on+0x10d/0x14e [<c011ac85>] tasklet_action+0x3d/0x68 [<c011abba>] __do_softirq+0x41/0x92 [<c011ac32>] do_softirq+0x27/0x3d [<c0105134>] do_IRQ+0x7b/0x8f [<c0103dec>] common_interrupt+0x24/0x34 [<c0103df6>] common_interrupt+0x2e/0x34 [<c0248e65>] acpi_processor_idle+0x1b3/0x34a [<c0248e68>] acpi_processor_idle+0x1b6/0x34a [<c010232b>] cpu_idle+0x39/0x4e [<c04bab0c>] start_kernel+0x372/0x37a [<c04ba42b>] unknown_bootoption+0x0/0x202 [<ffffffff>] 0xffffffff Signed-off-by: Jiri Kosina <jkosina@suse.cz> --- net/bluetooth/hci_sock.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c index f928d2b..71f5cfb 100644 --- a/net/bluetooth/hci_sock.c +++ b/net/bluetooth/hci_sock.c @@ -656,7 +656,7 @@ static int hci_sock_dev_event(struct not /* Detach sockets from device */ read_lock(&hci_sk_list.lock); sk_for_each(sk, node, &hci_sk_list.head) { - bh_lock_sock(sk); + lock_sock(sk); if (hci_pi(sk)->hdev == hdev) { hci_pi(sk)->hdev = NULL; sk->sk_err = EPIPE; @@ -665,7 +665,7 @@ static int hci_sock_dev_event(struct not hci_dev_put(hdev); } - bh_unlock_sock(sk); + release_sock(sk); } read_unlock(&hci_sk_list.lock); } ^ permalink raw reply related [flat|nested] 7+ messages in thread
end of thread, other threads:[~2007-03-05 15:34 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-03-04 14:53 [Regression] Bluetooth RFComm: using it locks up the machine Mark Lord 2007-03-04 15:12 ` Mark Lord 2007-03-04 17:33 ` Marcel Holtmann 2007-03-04 17:55 ` Mark Lord 2007-03-04 18:26 ` [PATCH] Fix 2.6.21 rfcomm lockups (2.6.21 regression) Mark Lord 2007-03-05 12:41 ` Cornelia Huck 2007-03-05 15:33 ` Jiri Kosina
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
