summaryrefslogtreecommitdiffstats
path: root/include/net
diff options
context:
space:
mode:
authorMarcel Holtmann <marcel@holtmann.org>2008-11-30 12:17:29 +0100
committerMarcel Holtmann <marcel@holtmann.org>2008-11-30 12:17:29 +0100
commit9a5df92374d65e2886b92e98dd7d873c533a83ff (patch)
tree0e45cc166ce12c42cb7a94cac2dd82e255552120 /include/net
parent2e792995e4cb425422dc379c3618447c462756a8 (diff)
downloadtalos-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 'include/net')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud