Hi,
When a task (or even IRQ handler) on one CPU tries to unlink, the requestCalls to usb_unlink_urb() while the completion handler is running won't do anything until the handler has returned.It still violates the API spec: there's no completion callback with an unlink status (-ECONNRESET, -ENOENT). It shouldn't masquerade as a call that behaved correctly (unlink status callback guaranteed).
I don't think I understand your objection. Are you saying that if a
driver calls usb_unlink_urb() while the urb's completion handler is
running, then back when the handler was originally called the value of
urb->status wasn't -ECONNRESET or -ENOENT?
may be in MANY stages of completing on another CPU. That shouldn't matter
at all to whatever is unlinking ... in your patch, it _did_ matter.
> That's clearly unavoidable and
hardly a violation of the API spec; after all, the instance of the urb for which the handler is running _wasn't_ cancelled (at least, not by this call to usb_unlink_urb()).
But you're returning a success code, reporting that it was. Ignoring the issue of whether the unlink request is synchronous, discarding the current -EBUSY return code means that drivers written to block until they get an -ECONNRESET or -ENOENT completion would never wake up.
And that'd be because of what happened to be running on another CPU. Or because of when something got preempted, and so on.
I've still got a bunch of messages in my inbox, maybe one of them will persuade me that (2) needs solving. I can't yet see why though; particularly the "... and its handler has exited" part, since that's easily guaranteed by calling synchronize_kernel().
Maybe it doesn't really need solving. But as things stand, the API spec probably could use some revision. It says:
* When the URB_ASYNC_UNLINK transfer flag for the URB is clear, this
* request is synchronous. Success is indicated by returning zero,
* at which time the urb will have been unlinked,
* and the completion function will see status -ENOENT.
I note that this makes no guarantees about when the completion function will run with respect to the return from usb_unlink_urb(); it only says that the status will be -ENOENT and that the urb will have been unlinked.
Maybe it should have said completion function "will have seen", but I don't naturally gravitate to the future perfect tense! :) But you seemed to be concerned about when the completion function finishes, while all that does is talk about when it starts. With HCDs using the "hcd.c" code we know that answer. I'd not object to requiring all HCDs to do that, since I'm not involved with any of the ones that would need to change. - 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
