On Wednesday 26 July 2006 7:16 am, Alan Stern wrote:
> On Tue, 25 Jul 2006, David Brownell wrote:
>
> > > Or are you referring to the second sentence in the comment? It doesn't
> > > mention asynchronous unlinks in particular; it just says that interrupts
> > > have to be enabled.
> >
> > Yes. One of the basic reasons to be async is so you can run with
> > irqs disabled. I should probably have written "unlinked with irqs
> > disabled".
> >
> > And the attached patch works just fine, removing that inappropriate
> > restriction. At least in the "rmmod" case I saw.
>
> 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;
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), 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.
- 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
