On Thursday 29 March 2007 11:58 pm, Oliver Neukum wrote: > /* complete() can reenter this HCD */ > spin_unlock (&ehci->lock); > usb_hcd_giveback_urb (ehci_to_hcd(ehci), urb); > spin_lock (&ehci->lock); > > The comment gives you the reason and is right. The locks must be dropped. > Therefore, if the urb is resubmitted while the completion handler is running, > usbcore will fully process this urb.
Well, "fully" as in "hand it back to the HCD" (it's effectively a new URB). > This means that the status will be set to -EINPROGRESS. > So the status is valid only until the urb is resubmitted. The driver > in question may resubmit the urb in the write path if !port->write_urb_busy. > > We must consider clearing a busy flag equivalent to resubmitting the > urb ourselves. Sounds like the issue would be a locking bug with respect to that driver-internal flag ... > In a completion handler that resubmits the urb you do that > resubmission last in the handler, don't you? And before then, urb->status won't change, since nobody else is using that URB. If not, that's clearly a locking bug... > As an added complication, the resubmission would happen on another cpu. > Therefore the order on the bus must be correct, hence the "smp_mb()". Erm, resubmit would happen on the CPU running the completion handler. So, no mb() or even smp_mb() is required for resubmit-from-compltion. - Dave ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
