linux-kernel - [patch 0/5] genirq: Forced 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-next>] [day] [month] [year] [list]

Message-Id: <20110223231601.613115832@linutronix.de>
Date:	Wed, 23 Feb 2011 23:52:11 -0000
From:	Thomas Gleixner <tglx@...utronix.de>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>
Subject: [patch 0/5] genirq: Forced threaded interrupt handlers

Some time ago when the threaded interrupt handlers infrastructure was
about to be merged, Andrew asked me where that command line switch was
which magically runs all interrupt handlers and the softirqs in
threads.

While we were doing that brute force in preempt-rt for quite a while
it took some time to come up with a reasonable non intrusive
implementation for mainline. We also had to find a solution which fits
Linus' recently issued "palatable Trojan horse" requirement (see:
https://lwn.net/Articles/370998/).

The gift of this patch series is the ability to add "threadirqs" to
the kernel command line and magically (almost) all interrupt handlers
- except those which are explicitely marked IRQF_NO_THREAD - are
confined into threads along with all soft interrupts.

That allows to enhance the debugability of the kernel as a bug in an
interrupt handler is not necessarily taking the whole machine
down. It's just the particular irq thread which goes into nirwana. Bad
luck if that's the one which is crucial to retrieve the bug report,
but in most cases - yes, I analysed quite a lot of bugzilla reports -
it will be helpful for reporters not to be forced to transcribe the
bug from the screen.

An architecture has to enable that feature in Kconfig via a selectable
option which says: Yes, we marked all interrupts which never can be
threaded - like IPIs etc. - as IRQF_NO_THREAD. All interrupts marked
IRQF_TIMER or IRQF_PER_CPU are automatically excluded from threading.

A side effect of this is, that the long standing request of supporting
oneshot threaded handlers on shared interrupt lines (given that all
drivers agree) is now possible. I know, that this is nuts, but
unfortunately common sense and basic understanding of the problem
seems to be not required when HW folks are set out to save a gate.

Thanks,

	tglx
---
 Documentation/kernel-parameters.txt |    4 +
 include/linux/interrupt.h           |   13 +++
 include/linux/irqdesc.h             |    2 
 kernel/irq/Kconfig                  |    3 
 kernel/irq/handle.c                 |   34 +++++----
 kernel/irq/internals.h              |    2 
 kernel/irq/manage.c                 |  128 +++++++++++++++++++++++++++++++-----
 kernel/sched.c                      |    5 +
 kernel/softirq.c                    |   16 +++-
 9 files changed, 175 insertions(+), 32 deletions(-)

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