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. > 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? > 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. 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! 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? Alan Stern ------------------------------------------------------------------------- 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
