> Unlinking is tricky, and my understanding of the current rules are:
>
> - For a successful synchronous unlink, the completion handler did fire
> before the unlink call returned. Easily proven for HCDs that go through
> the "hcd.c" logic (*), otherwise you have to take it on faith. (And
> some older HCD code might bugs here, like not reporting completions.)
Good.
> - For a successful asynchronous unlink, the only rule is that the
> completion handler _will_ be called with urb->status == -ECONNRESET.
> Maybe before usb_unlink_urb() returns, maybe after. (I've certainly
> seen "before" in certain fault recovery scenarios, and SMP ought to
> allow it too, although "after" is more usual.)
Best we can do.
> - For _un_successful unlinks of either type, look at the returned status
> to figure out what's up. For example, "-EBUSY" (now) says that the
> urb was going through a normal (including non-cancellation fault)
> return process, -EINVAL and -ENODEV also give useful status.
>
> The "devio.c" code quoted didn't handle the unsuccessful unlink case,
> which I suspect is pretty typical.
Sadly yes. We could avoid this bug if we waited.
Now for something related.
From usb_submit_urb():
if (!(op = dev->bus->op) || !op->submit_urb)
return -ENODEV;
urb->status = -EINPROGRESS;
<--- here begins the window
urb->actual_length = 0;
urb->bandwidth = 0;
What happens if usb_unlink_urb() is called right there? Nothing good
it seems to me. One nasty failure mode might be khubd stuck in state
D, if the endpoint is stalled.
Regards
Oliver
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
