diff options
author | Marcel Holtmann <marcel@holtmann.org> | 2008-11-30 12:17:29 +0100 |
---|---|---|
committer | Marcel Holtmann <marcel@holtmann.org> | 2008-11-30 12:17:29 +0100 |
commit | 9a5df92374d65e2886b92e98dd7d873c533a83ff (patch) | |
tree | 0e45cc166ce12c42cb7a94cac2dd82e255552120 /mm/quicklist.c | |
parent | 2e792995e4cb425422dc379c3618447c462756a8 (diff) | |
download | talos-op-linux-9a5df92374d65e2886b92e98dd7d873c533a83ff.tar.gz talos-op-linux-9a5df92374d65e2886b92e98dd7d873c533a83ff.zip |
Bluetooth: Fix RFCOMM release oops when device is still in use
It turns out that the following sequence of actions will reproduce the
oops:
1. Create a new RFCOMM device (using RFCOMMCREATEDEV ioctl)
2. (Try to) open the device
3. Release the RFCOMM device (using RFCOMMRELEASEDEV ioctl)
At this point, the "/dev/rfcomm*" device is still in use, but it is gone
from the internal list, so the device id can be reused.
4. Create a new RFCOMM device with the same device id as before
And now kobject will complain that the TTY already exists.
(See http://lkml.org/lkml/2008/7/13/89 for a reproducible test-case.)
This patch attempts to correct this by only removing the device from the
internal list of devices at the final unregister stage, so that the id
won't get reused until the device has been completely destructed.
This should be safe as the RFCOMM_TTY_RELEASED bit will be set for the
device and prevent the device from being reopened after it has been
released.
Based on a report from Vegard Nossum <vegard.nossum@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Diffstat (limited to 'mm/quicklist.c')
0 files changed, 0 insertions, 0 deletions