On Wed, 5 May 2004, David Brownell wrote: > >>This disconnect() issue is a parallel of the open()/disconnect() issue. > >>In both cases, there's state that must linger after disconnect() returns, > >>and be cleaned up later. In one case it's what close() accesses, and it's > >>associated with a user file handle. In the other case, it's what the > >>SCSI EH task will have to work with as it's noticing -ENODEV. > > > > > > That is wrong. It's not simply a question of lingering state; it's also a > > question of lingering code. After disconnect() returns we have to assume > > that the driver is no longer resident in memory. Unlike open(), > > Usbcore certainly does. But the device driver doesn't need to make > such assumptions unless they're true. And in this case they'd > clearly be false!
Leaving that aside for the moment, you're arguing that usb_reset_device() should be allowed to block until after the driver is unbound from the device. Doesn't this violate the principle that once a driver's disconnect() has returned, the driver is not allowed to do _anything_ to a device? How is usb_reset_device() supposed to know that the unbinding happened and hence it should fail? It doesn't even know which interface(s) the driver calling it was bound to! > > usb_reset_device() doesn't take a reference to the driver's module. > > Hence there can't be any threads (like SCSI EH) still trying to use it. > > That would be a driver bug: the EH thread would have taken an extra > reference to the device, and certainly should have refcounted it > before dropping the lock which allowed disconnect() to start. > > (And maybe an extra reference to the driver module, but that sounds > more like something SCSI should have done to usb-storage.) Actually the SCSI core does both. The EH thread doesn't take any special references. To compensate, the core doesn't drop its references until the EH is through. (And BTW I named the wrong routine below; it should be scsi_remove_host(), not scsi_unregister_host().) > > Let's also consider the special case of usb-storage, and let's suppose for > > a moment that the module won't be removed from memory when disconnect() > > returns. It's _still_ a problem, because disconnect() calls > > scsi_unregister_host() and that routine won't return until the EH has > > finished. > > A similar observation applies. Although that one might be harder > to resolve, since in this case it's SCSI that's placing curious > synchronization problems on the rest of Linux. It's still not all > that hotplug-friendly, I guess ... or the "unregister host" call > would let tasks currently using that host stop doing so at their > own rate, rather than expect that they do so "right now". > > If one thinks of refcount models (which have limitations!), the > disconnect() call, like unregister_host(), is just a way to drop > one "special reference". There'd often be other refcounts, like > ones given out through sysfs and other channels. Each of those > references would need to be individually released later ... when > the component with the reference learns that it's stale, and does > its own particular cleanup. The SCSI core still hasn't fully integrated the hotplug/reference-counting approach, as you say. Mike Anderson has been working on this for a long time, but the host registration part still has a ways to go. On the other side, maybe USB hasn't gone all the way either. Calling a driver's disconnect() is how we revoke the usb_device/interface pointer that was passed to probe(). If the driver has a thread blocked in usbcore somewhere, waiting on a semaphore, how can it tell that thread the usb_device pointer is now stale? Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
