summaryrefslogtreecommitdiff
path: root/sound/ac97_bus.c
diff options
context:
space:
mode:
authorMarcel Holtmann <marcel@holtmann.org>2008-11-30 11:17:29 (GMT)
committerMarcel Holtmann <marcel@holtmann.org>2008-11-30 11:17:29 (GMT)
commit9a5df92374d65e2886b92e98dd7d873c533a83ff (patch)
tree0e45cc166ce12c42cb7a94cac2dd82e255552120 /sound/ac97_bus.c
parent2e792995e4cb425422dc379c3618447c462756a8 (diff)
downloadlinux-9a5df92374d65e2886b92e98dd7d873c533a83ff.tar.xz
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 'sound/ac97_bus.c')
0 files changed, 0 insertions, 0 deletions