mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-09-04 09:59:32 +00:00
[PATCH] Fix 2.6.21 rfcomm lockups
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* 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) | commitc1a3313698
| tree337a876f72
tree | snapshot | parentf5ffd4620a
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> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
parent
166f60dde0
commit
0de1517e23
1 changed files with 2 additions and 0 deletions
|
@ -431,6 +431,8 @@ int sysfs_move_dir(struct kobject *kobj, struct kobject *new_parent)
|
|||
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)) {
|
||||
|
|
Loading…
Reference in a new issue