On Wednesday 26 July 2006 8:29 am, Alan Stern wrote: > On Wed, 26 Jul 2006, David Brownell wrote: > > > > The patch uses spin_lock_irqsave() and spin_unlock_irqrestore() along with > > > a call to wait_event(). What happens if you end up calling wait_event() > > > with interrupts disabled? Would it be better simply to spin? > > > > You're ignoring that ugly > > > > if (in_interrupt()) > > return 0; > > You're forgetting that in_interrupt() is different from irqs_disabled(). > In fact, either may be true independent of the other.
Although I don't think any of the current HCDs allow IRQs to be enabled while their handlers run ... so in_interrupt() implies irqs_disabled(). In the more general case your observation is of course correct. > > Arguably the best thing to do on that branch -- control requests -- would > > be to make that the equivalent of "if (1)". Control requests to root > > hubs are always synchronous (and often done with IRQs disabled), > > Says who? Can you point to any examples of control requests to root hubs > that are done with interrupts disabled? EHCI, OHCI, and UHCI all need to implement those requests with IRQs disabled, since they need to access registers protected by spin_lock_irqsave() ... > > so the > > worst that would happen is that some other CPU would give the urb back > > shortly after that routine returns, rather than shortly before it does so. > > That's _not_ the worst. The code used to be that way, and I changed it > after it caused a crash. I'm not following. Which way -- equivalent to if(1)? > The problem came up when there was a control URB running while the HCD > module was unloaded. hcd_endpoint_disable() didn't wait for the URB to > complete, the driver was unloaded from memory, and boom! Hmm, the if(1) should leave the urb in ep->urb_list so hcd_endpoint_disable() would go through the loop again, retrying until the urb completed. Or was there something else going on? (It's late, sigh.) > Nowadays we can prevent the crash with appropriate refcounting. But it > could still leave us calling hcd->driver->stop() while the control URB was > running. Do you think it would be safe, given how non-standardized those > HCD methods are? I'm missing something. Refcounting wouldn't solve that; the issue is that the URB wasn't yet given back, and thus is on ep->urb_list (with a refcount, sure, but _because_ it's on the list and thus still busy). So stop() wouldn't be called ... if HCDs don't behave the same, that's clearly trouble. - 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
