So all's fine at the HCD/usbcore interface. But the result is that an URB state went from being relatively rare (on 2.4 USB) to common (2.6/UHCI) ... which can oops drivers that don't handle that state correctly, and there are more than a few.
What URB state do you mean? Surely not "unlinked but still in use" -- that is no more common now than it ever was. Anyway it's not the state that's the problem. The problem is that the state is now quite likely to occur at a time when the driver is awake and active, namely, during unbinding.
The now-more-common state is "sitting on UHCI complete_list". Subcases include "unlinked", "shut down", "normal completion", and "I/O error".
(Neither OHCI nor EHCI have such a state; it comes from the QH-per-URB approach.)
If _all_ HCDs addressed that second point, almost all logic in driver disconnect() relating to unlinking URBs could be removed. That's most of the synchronous unlink calls ... that'd be a good way to get rid of all the synchronous unlink bugs! :)
All except for the ones not associated with disconnect. In the bluetooth
driver, for example, exactly the same code is also used for device close. The same problem could have cropped up there too, if a packet was received
from the device at the wrong time. Of course that's much less likely.
Right. I meant to type "most of the synchronous unlink bugs", and the fact that this driver uses that in close() code is a good illustration of there being two inter-related bugs ... :)
This particular problem doesn't count, since it could crop up in other situations where disable_endpoint() hadn't been called, even for OHCI.
Except they're rare. Almost all current synchronous unlink calls from USB drivers are in disconnect() entries -- and hence almost all the driver bugs in that area.
I kind of like the idea of having an obscure problem like this _not_ be rare, so that it shows up early and is easy to diagnose and fix. If
I certainly understand the contribution of "fail-fast" to robust implementations! Though I'm not keen on HCD-specific behaviors, especially avoidable ones.
UHCI _had_ implemented disable_endpoint and someone encountered that race while closing the bluetooth device, it would have been impossible to reproduce or find the error.
If it was "impossible" it wouldn't be a problem though would it? :)
But that's an exaggeration ... it would have appeared in the close() path, infrequently but consistently, and would look more obviously like a usb device driver bug since it would appear with all HCDs.
- 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
