Alan Stern wrote:
On Wed, 19 Feb 2003, David Brownell wrote:
That assumes an incorrectly written disconnect() routine. And
the two changes identified (did you notice that SCSI hot-unplug
discussion identified _exactly the same_ two changes??) would
prevent that happening: (a) no more submissions are possible,
(b) something nukes all pending urbs.
For (b) there are several options. Today we expect (b1) device
driver handles all in disconnect(), except that to guard against
bugs there sometimes (b2) HCD may need to get involved. I'd
think a cleaner solution would be (b3) usbcore kills them all;
less work for device drivers too.
It sounds to me like this is really a question of how far do you want to
trust device drivers. AFAIK, there is nothing at all to prevent a driver
from submitting an urb for a totally different device (i.e., one that it
isn't controlling), never mind submitting an urb for an interface after
disconnect()-ing. In fact, usb_submit_urb() doesn't even know which
driver called it.
I think it's not legal for a driver to submit urbs to devices
they've not claimed, except if they're probe()ing that device.
In fact, how did they even find out about such a device?
Your second case is (a) and Greg's usbdev->present flag (now in
Linus' tree) prevents it on the "physical disconnect" path.
Now I admit, the first of these is much less likely than the second. But
the fact remains, you have to decide how much responsibility you want to
leave to the driver and how much to assume in the core. Part of the
current problem may be that the rules are not clearly stated -- I wouldn't
know about that.
My personal feeling is that basically drivers should be trusted to do
what's right (and fixed when they don't). The core should do just enough
checking to make sure that a badly-behaving driver can't crash the kernel.
It's not just "trust". There's also the option in many cases of just
having a design that doesn't _allow_ certain will-crash behaviors.
And that's exactly where (a) and (b) came from: the premise that
disconnect logic shouldn't give drivers so much rope, so that even
if they do misbehave, they won't break things very badly.
Depending on how the HCD's are written, (a) may or may not be necessary,
although it probably wouldn't hurt in any case. (b) is a different story,
and is considerably complicated by the need to take into account module
unloading, port resets, configuration and altsetting changes, in addition
to physical disconnects.
I guess I don't see how an HCD could affect (a), or how (b) would be
different in those cases. In all those config change events, and
reset/disconnect events, usbcore certainly knows enough to do the
right thing -- but it doesn't, in part because it's missing the right
kinds of primitive.
I'd submit some patches in this area, but other things are consuming
my time just now, so ... I was very glad to see Greg fix part of (a)! :)
- Dave
Alan Stern
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
