Thread (106 messages) flat view 106 messages, 13 authors, 2009-07-22

Re: lockdep and threaded IRQs (was: ...)

From: Peter Zijlstra <hidden>
Date: 2009-03-02 22:25:56
Also in: linux-input

On Mon, 2009-03-02 at 14:10 -0800, David Brownell wrote:
What's unfortunate is that you prefer not to fix that
IRQF_DISABLED bug in lockdep, which you co-"maintain".
When running with lockdep, that bug (a) introduces bugs
in some drivers and (b) hides bugs in others.  You've
rejected even a minimal warning fix, to help minimize
the amount of time developers waste on (a) and (b).
I've come to the conclusion that the only technically sound solution is
to do as I proposed today, utterly eliminate !IRQF_DISABLED handlers.

Apparently you had enough time to come up with the creative genirq abuse
of twl4030, I think that with a similar effort you could have
implemented generic threaded irq stuff like proposed by Thomas.
Attacking folk for having to cope with such bugs escalates
things beyond "unfortunate".  If lockdep is "maintained",
your response should be fixing that lockdep bug.  Once
that's done, all workarounds for that bug can be removed.
I state there is no lockdep bug in this respect. The bug is trying to
enable interrupts from hardirq context and running code that assumes
hardirq context from task context.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help