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]

Message-Id: <1235719113.4948.1252.camel@laptop>
Date:	Fri, 27 Feb 2009 08:18:33 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, rostedt@...dmis.org,
	jonathan@...masters.org
Subject: Re: [patch 4/4] genirq: add support for threaded interrupt handlers

On Thu, 2009-02-26 at 21:45 -0800, Andrew Morton wrote:
> On Thu, 26 Feb 2009 21:27:52 -0800 Arjan van de Ven <arjan@...radead.org> wrote:
> 
> > > 
> > > 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.
> 
> I was actually kinda surprised by the patch - it needs moderate changes
> to each driver.  I'd have thought that it would be possible to arrange for
> _all_ drivers to have their interrupt handlers automagically called from
> process context with no driver changes.
> 
> Did anyone ever try that?  I think they did...

Yes, current preempt-rt does exactly that, as mentioned in the
changelog. That same changelog also mentions why this isn't such a hot
idea:

"The implementation provides an opt-in mechanism to convert drivers to
the threaded interrupt handler model contrary to the preempt-rt patch
where the threaded handlers are enabled by a brute force switch. The
brute force switch is suboptimal as it does not change the interrupt
handler -> tasklet/softirq interaction problems, but was the only way
which was possible for the limited man power of the preempt-rt
developers."

So the idea is that we want people to re-think and change their
interrupt routines to take advantage of the benefits of threaded
interrupts and avoid the endless context switching between threaded
interrupts handler, softirq/tasklet/workqueue contexts, which preempt-rt
now has.

The only way to avoid that is by pushing all softirq/tasklet/worklet
code into the threaded handler, and the only way to do that is by
reworking the drivers.

Since there are too many drivers to count on our few hands, we need an
opt-in, so that we can gradually migrate towards this scheme.

--
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/