On Tue, 18 Feb 2014, Stanislaw Gruszka wrote: > On Mon, Feb 17, 2014 at 09:48:14AM -0500, Alan Stern wrote: > > On Mon, 17 Feb 2014, Stanislaw Gruszka wrote: > > > > > There is threadirqs kenel boot option which allow to force interrupt > > > routines to be performed as thread. > > > > > > USB irq routines use spin_lock(*hci->lock) variant without disabling > > > interrupts, what is perfectly fine, but that can cause deadlock when > > > forced thread irqs are used. Deadlock scenario is quite reproducible for > > > me, as I can not boot system with threadirqs option, when some USB > > > device is connected. Patch marks USB irq routines with IRQF_NO_THREAD > > > to prevent forced threading. > > > > This doesn't explain the entire story. As far as we know the deadlock > > affects only ehci-hcd, because only ehci-hcd uses an hrtimer callback, > > and hrtimer callbacks run in interrupt context even when threadirqs is > > specified. > > Yes, you have right. > > > Maybe the patch should include a comment explaining that the > > IRQF_NO_THREAD flag will not be needed when hrtimer callbacks are > > threaded. > > I can add that to the patch, but perhaps better would be to just > change ehci_irq to use spin_lock_irqsave, that will allow to have > threaded interrupt in cost of very little penalty. Either approach would be acceptable to me. Using IRQF_NO_THREAD avoids the extra overhead of spin_lock_irqsave when IRQs aren't threaded. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
