On Mon, 13 Jan 2003, Oliver Neukum wrote:

> Let me explain.
> The first problem we avoid is with unloading. We want to be sure that
> the completion handler is not running after return from usb_unlink_urb().
> If we wish to make the guarantee, usb_unlink_urb() must not simply
> fail if the completion handler is running. A synchronous unlink must wait.
> 
> The second problem we fix is with resubmission from the completion
> handler. If we have a state for unlinked during completion, we can fail
> resubmission. Thus we kill races with disconnect in rx paths.

This is highly analogous to the problem of cancelling a kernel timer.  If 
the timer's handler reschedules another timer interrupt, it can be hard to 
cancel reliably.  For kernel timers, the problem was only partially solved 
by having del_timer() return a code indicating whether or not the timer 
was still active and by adding del_timer_sync().  There still has to be a 
requirement that the handler must avoid restarting the timer.

Much the same is true for USB.  No matter what the core does, if the
user's completion handler resubmits, it will be hard to kill the URB 
entirely.

Furthermore, there is a conceptual problem that has not been fully 
addressed.  When a usb_unlink_urb() is called for an URB whose completion 
handler is running, which incarnation are we being asked to cancel?  The 
one that just completed or the one that the completion handler is about to 
submit?  If you can't answer this question first, then naturally you don't 
know what you're supposed to do.

As far as guaranteeing that when usb_unlink_urb() returns from a
synchronous unlink, the completion handler will have already finished --
so far as I can tell there is currently no such guarantee.  At least, the
kerneldoc preceding usb_unlink_urb() is sufficiently vague that it doesn't
make this promise.  Of course, we need to have something like this.  But
in principle there should be no problem -- or rather, the only problem is
dealing with the case that the handler resubmits.  What happens if the
handler resubmits the URB, and another thread tries to unlink the
newly-submitted incarnation before the handler has returned?

If it weren't for the fact that a completion handler is allowed to 
resubmit an URB, I suspect the best solution would simply be to lock the 
URB while the handler is running.

Alan Stern



-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to