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

[David Brownell <david-b@pacbell.net>]

On Sunday 01 March 2009, Thomas Gleixner wrote:
> On Sat, 28 Feb 2009, David Brownell wrote:
> > 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.
> 
> This can be solved by a completion as well.

One of many potential solutions; it's probably a better
use case for a counting semaphore though, especially if
they were all going in parallel.  And of course there's
the issue of where that synch code lives...

Though I still don't see any real issue with keeping it
simple and serializing them without creating new threads.
In terms of resource consumption, that simple solution is
clearly superior.


> > (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.)
> 
> Then all we need to provide in the generic code is a function which
> does not go through the handle_IRQ_event() logic and calls the action
> handler directly.

That is, something to replace handle_simple_irq() and
handle_edge_irq() flow handlers?  (irq_desc.handle_irq)


> Not rocket science to do that and better than using 
> a facility which is designed to run in hardirq context and expect that
> it works in thread context without complaints.

The main "complaint" is the pre-existing lockdep breakage.  :)

The need to call irq_desc.handle_irq() with IRQs disabled is a
bit strange, but not really a problem; and it ensures consistent
locking for the irq_desc statistics and flag updates.

- Dave