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