On Thu, 13 Feb 2014, Thomas Gleixner wrote: > On Wed, 12 Feb 2014, Alan Stern wrote: > > I have no idea what might have changed between 3.12 and 3.13 to cause > > this problem. Maybe Thomas can figure it out. > > > > > And yes, the issues goes away when no thread irqs are used (with and > > > without the patch). > > > > Thomas, there must be some reason why the patch below is wrong, but I > > don't know enough about the IRQ subsystem to tell what's really going > > on. Can you explain it? > > If we force all interrupts into threading, then there is no reason to > disable interrupts and lockdep should not complain at all because all > accesses happen in thread context. > > Now the ehci case is different: > > The hrtimer callback (ehci_hrtimer_func) still runs from hard > interrupt context and is of course taking the lock which in turn > causes lockdep to yell. > > So the local_irq_save() in the usb interrupt handler was hiding the > issue so far. That's why reverting 88ed9fd50e cures it. Okay, that's understandable. > On RT we cure it differently as we move all hrtimers which are not > explicitely marked as hardirq safe into the threaded softirq context. Why doesn't the vanilla kernel do that also? Without it, the "threadirq" boot-line parameter isn't safe. > Not sure what's the best solution to solve this, but I really want to > avoid the general interrupt disable in the forced threaded mode. > > The simple solution is of course to take the lock in ehci_irq with > spin_lock_irqsave(), but it's not that pretty either ... I can think of two other solutions. The first is to move the non-hardirq-safe hrtimers into threaded softirq context, as mentioned above. The second is for ehci_hrtimer_func to schedule a tasklet instead of doing its work directly. But this seems like an awkward workaround for something which shouldn't be a problem in the first place. Of the three, using spin_lock_irqsave in ehci_irq is the simplest. If the hrtimers can't be moved to threaded context, that's what I'll end up doing. 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
