aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/qlge
diff options
context:
space:
mode:
authorJames Woodcock <James.Woodcock@ACULAB.COM>2009-02-11 10:06:53 -0500
committerGreg Kroah-Hartman <gregkh@suse.de>2009-03-24 19:20:31 -0400
commit331879fd6f584d60327ba802616d41bfa636b873 (patch)
tree0cb4c0b41d16242ea27e2206bc13d9eaeb020bf3 /drivers/net/qlge
parent1c27ae671e6b465e04544450276c88f4dba8de60 (diff)
USB: serial: refuse to open recently removed USB Serial devices
A USB-serial converter device is plugged into a system, and a process opens it's device node. If the device is physically removed whilst the process still has its device node open, then other processes can sucessfully open the now non-existent device's node. I would expect that open() on a device that has been physically removed should return ENODEV. This is manifesting itself with getty on my system. I do the following: 1. set up inittab to spawn getty on ttyUSB0, eg: T1:23:respawn:/sbin/getty -L ttyUSB0 115200 vt100 2. Plug in USB-serial converter cable 3. Wait for a login prompt on a terminal program attached to the serial cable 4. Login 5. Pull the USB-serial converter cable from the box 6. getty doesn't realise that ttyUSB0 no longer exists as /dev/ttyUSB0 can still be opened. 7. Re-insert the USB-serial converter cable 8. You should no longer get a login prompt over the serial cable, as the the USB-serial cable now shows up as /dev/ttyUSB1, and getty is trying to talk to /dev/ttyUSB0. The attached patch will cause open("/dev/ttyUSB0", O_RDONLY) to return ENODEV after the USB-serial converter has been pulled. The patch was created against 2.6.28.1. I can supply it against something else if needs be. It is fairly simple, so should be OK. I am using a pl2303 device, although I don't think that makes any difference. From: James Woodcock <James.Woodcock@ACULAB.COM> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'drivers/net/qlge')
0 files changed, 0 insertions, 0 deletions