On Sat, 2004-04-03 at 20:40, Alan Stern wrote: > Without having looked recently in any detail at the specific code in sd.c > or sr.c, I want to comment in general terms on the nature of the > open/disconnect race. > > It's a generic problem that affects every driver whose devices can be > opened through the filesystem. It _cannot_ be solved by adding any sort > of lock to the device structure. This is because the device structure is > not available to the open() routine until it has followed some pointer > from the major/minor device table entry, and the disconnect() routine will > erase the pointer. That (or someplace equivalent) is where the race > occurs.
OK, your "problem" definition is that "there's a race", which I agree with, I just don't agree that it's a problem. Disconnections are fundamentally asynchronous events (a device may be disconnected by the user at any stage regardless of what any kernel internal state model is doing). Trying to impose synchronisation on asynchronous events is asking for trouble. In the open race scenario, either the open is refused or the user gets a fd that cannot do anything (because the device isn't there) and simply returns errors to all operations. Both cases are correct, so who wins the race is irrelevant. 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. James > The problem _can_ be solved by introducing a lock higher up, such as at > the driver level or at the bus level. (A kernel lock would work too but > it would be extravagantly excessive.) For example, the bus subsystem > rwsem in the driver model prevents analogous problems there. But you > don't want to get a read lock on a bus-wide semaphore every time your > open() procedure runs! A driver-wide lock makes a good solution. > > Another possible solution would be to have disconnect() perform an RCU > update to the device pointer. I haven't seen any code that does this, but > I think it ought to work. > > Alan Stern > > - > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html ------------------------------------------------------- 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
