linux-kernel - Re: [patch 4/4] genirq: add support for threaded interrupt handlers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 26 Feb 2009 21:27:52 -0800
From:	Arjan van de Ven <arjan@...radead.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
	mingo@...e.hu, peterz@...radead.org, rostedt@...dmis.org,
	jonathan@...masters.org
Subject: Re: [patch 4/4] genirq: add support for threaded interrupt handlers

On Thu, 26 Feb 2009 15:32:16 -0800
Andrew Morton <akpm@...ux-foundation.org> wrote:

> On Thu, 26 Feb 2009 13:28:23 -0000
> Thomas Gleixner <tglx@...utronix.de> wrote:
> 
> > Add suppport for threaded interrupt handlers. This is a more strict
> > separation of the primary interrupt handler, which runs in hard
> > interrupt context, and the real interrupt handler, which handles the
> > real device functionality, than the existing hardirq/softirq
> > separation.
> > 
> > The primary hard interrupt context handler solely checks whether the
> > interrupt originates from the device or not. In case the interrupt
> > is asserted by the device the handler disables the interrupt on the
> > device level. This must be the only functionality of the primary
> > handler and this restriction has to be carefully monitored to avoid
> > unresolvable locking scenarios with a fully preemptible kernel.
> > 
> > The threaded handler allows to integrate hardware related
> > functionality and softirq/tasklet functions in the handler
> > thread.
> > 
> 
> A typical device driver will do:
> 
> some_function(...)
> {
> 	spin_lock_irqsave(&dev->lock);
> }
> 
> irq_handler(...)
> {
> 	spin_lock(&dev->lock);
> }
> 
> and this does not deadlock, because the driver "knows" that the IRQ is
> disabled during the execution of the IRQ handler.
> 
> But how is this optimisation supported with IRQ threads?  Do we leave
> the IRQ disabled during the thread execution?  Or does the driver need
> to be changed?
> 
> Bearing in mind that the driver might choose to split the IRQ handling
> between hard-irq context fastpath and process-context slowpath (I
> hope), and that each path might want to take the same lock.
> 


Realistically, for the "we go threaded interrupts" case (which is
opt-in), I think the only sane option is
* the quickhandler runs with irqs off
* the "slow" threaded handler runs with irqs on
And we guarantee both of these conditions from the core, to the point
that I think we should not allow any other combination.

This also should be fine for basically all cases; the quick handler
really needs to be quick so irq off makes sense, and the slow handler
can, worst case, turn off interrupts by itself, but normally is
preemptable etc etc.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/