Greg KH wrote:
On Wed, Feb 19, 2003 at 02:21:11PM -0800, David Brownell wrote:
Greg KH wrote:
Hm, maybe we should mark the device gone at the beginning of this call,
or right at the time we realize it's gone in the hub driver. That would
keep drivers from submitting urbs from within their disconnect
functions. But it would also prevent them from canceling them... Ah,
Only because you put that check in the unlink path ... I think it'd
be better to mark earlier, and allow cleanup at any time (not check).
No, some of the hcds die a horrible death if you try to call unlink on a
urb after the device is gone :(
You mean with urb->dev null, or what? It ought to be fine; remember
that only usb_submit_urb() would really be testing udev->present,
so I don't see how that could happen without nulling urb->dev ...
In the gadget code I posted, I've made a point of making sure that
when the host goes away, or an endpoint gets disabled, the cleanup
paths continue to work ... only methods like enabling endpoints or
submitting requests get blocked. So things start to quiesce right
away, and shutdown is guaranteed to work in one pass, there's no
need to patch it up later.
No reason the host side can't use the same approach.
Sure, fixing up the host controllers would be fine. I wouldn't mind
that, and then removing the check on unlink. But I don't think it's a
requirement as things seem to work the way they currently are (although
I'm waiting for Oliver to find a race somewhere :)
I think "seems to work" is the right phrasing. It's combinations
of bugs -- as seen in the Real World -- that cause the trouble.
All I'm saying is that it's practical (and IMO desirable) to
prevent those combinations from creating trouble.
then we don't know when the callback would have happened to be able to
unload the driver safely...
I don't see why that would matter in that routine;
that seems like a different discussion.
No, you're saying that if a driver's disconnect() function has
completed, it is now safe to unload, right? Well if the hcd driver
Of a correctly written disconnect(), yes: because no urbs are in
flight, by definition.
hasn't cancelled the urb on device disconnect, then the callback can
still happen, in the driver module. Which could have just been
unloaded, oops :)
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.
Nah, I think it's good where it is, if a driver is trying to do
something when disconnect happens on it, the hcd can handle any problems
if the present flag isn't set exactly when disconnect is happening, as
it has to be able to do that right now, correct?
It's always been messy there, and rather than requiring the HCDs to do
more work, I'd much rather see them do less ... by guaranteeing that
those more exotic cases will never appear.
How do we prevent that from never appearing?
Prevent from never appearing ... leave code the way it is today!
But I hope you mean "prevent from appearing" ... ;)
For the cases I focussed on here, changing those two lines I mentioned
to make (a) happen early enough to leave (b) be the only problem:
- usb_unlink_urb() ignores dev->present.
- usb_disconnect() sets dev->present first thing.
I may provide such a micropatch next time I sync up with your tree,
if nobody beats me to it.
- Dave
-------------------------------------------------------
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
