Oliver Neukum wrote:
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.
Yes, I'd like to see this fixed. Needs more thought than I have time
to apply to that problem though, and a 2.5 fix might not be practical.
Luckily I think most code is currently structured to avoid that issue.
A really brief problem statement is that (unlike usb_sg_request) there
is no "initialized and cancelable, but not submitted" state. There's
"initialized"; then there's "submitted and cancelable". So two threads
can't naturally synchronize on the URB... they've got to synch on some
other data structure, and make the submit/complete/unlink paths do the
right things there.
- Dave
-------------------------------------------------------
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
