Let me illustrate: the user may disconnect the device then open it. If they open it before even the USB subsystem gets notified of the disconnection then all the elaborate synchronisation in the world isn't going to be able to prevent that (the device was gone when they opened it, just nothing in the kernel knew that). Since we cannot solve that race, there's no reason to try to solve the "some parts of the kernel know but others don't" part of the race.
You're assuming that synchronization is there to establish a single global notion of state. Clearly that's impossible; also undesirable.
The synchronization is actually there to let the "device gone" state spread cleanly through the software stack. By the time USB disconnect() is called, host controller drivers (and khubd) have normally cleaned up all hardware state, and usbcore is never going to accept another operation on that device. The disconnect() callback is there to prevent that raciness from making trouble ... closing windows from the bottom up.
The way usb-storage passes that up to the SCSI layer is by calling scsi_remove_host(). Bug 2400 shows up later, through the block layer (or is it just cdrom?) code. Did someone actually post the specific source code line in cdrom_release() that's oopsing?
- Dave
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
