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

On Saturday 28 February 2009, Thomas Gleixner wrote:

On Sat, 28 Feb 2009, David Brownell wrote:

quoted

Got a version that applies to mainline GIT?

http://tglx.de/~tglx/patches.tar.bz2 

Got it, thanks.

quoted

At a quick glance it looks like these patches don't cover
set_irq_chained_handler(), which would be trouble since
__setup_irq() doesn't get called in those cases.

Hmm, I did not think about chained handlers where the demux handler
needs to run in a thread as well. Usually demux handlers just have a
fast path kicking the particular real handlers.

That can't work when the demux needs to access state across
I2C in order to see which "real" handlers to kick.  :)

quoted

They should however handle simpler cases, like I2C devices
that only expose one IRQ instead of needing to demux several
dozen IRQs going to different drivers and subsystems.

And, not touching lockdep, the original ugliness will still
be needed (re-enabling IRQs in threaded handlers).

Err ? The threaded handlers run with interrupts enabled.

Hmm, I'll have a closer look.  You changed handle_IRQ_event()
which is where the relevant IRQF_DISABLED test kicks in.  In
your updated code, that pokes any quick_check_handler() and
then maybe pokes a per-IRQ thread.

That seems to presume a hardirq-to-taskirq handoff.  But the
problem case is taskirq-to-taskirq chaining, through e.g.
what set_irq_chip_and_handler() provided.  (Details not very
amenable to brief emails, just UTSL.)

Thing is, I'm not sure a per-IRQ thread can work easily with
that chaining.  The chained IRQs can need to be handled before
the top-level IRQ gets re-enabled.  That's why the twl4030-irq
code uses just one taskirq thread for all incoming events.

(Which of course is rarely more than one at a time, so there's
little reason not to share that task between the demuxing code
and the events being demuxed.  Interrupts that need processing
via I2C/SPI/etc are more or less by definition not frequent or
performance-critical.)

- Dave