linux-kernel - Re: [PATCH] genirq/manage: Reduce priority of forced secondary IRQ handler

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: <aM_5uXlknW286cfg@wunner.de>
Date: Sun, 21 Sep 2025 15:12:25 +0200
From: Lukas Wunner <lukas@...ner.de>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Crystal Wood <crwood@...hat.com>, Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@...hat.com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Clark Williams <clrkwllms@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
	Valentin Schneider <vschneid@...hat.com>,
	linux-kernel@...r.kernel.org, Attila Fazekas <afazekas@...hat.com>,
	linux-pci@...r.kernel.org, linux-rt-devel@...ts.linux.dev,
	Bjorn Helgaas <helgaas@...nel.org>,
	Mahesh J Salgaonkar <mahesh@...ux.ibm.com>,
	Oliver OHalloran <oohall@...il.com>
Subject: Re: [PATCH] genirq/manage: Reduce priority of forced secondary IRQ
 handler

On Sat, Sep 20, 2025 at 11:20:26PM +0200, Thomas Gleixner wrote:
> I obviously understand that the proposed change squashs the whole class
> of similar (not yet detected) issues, but that made me look at that
> particular instance nevertheless.
> 
> All aer_irq() does is reading two PCI config words, writing one and then
> sticking 64bytes into a KFIFO. All of that is hard interrupt safe. So
> arguably this AER problem can be nicely solved by the below one-liner,
> no?

The one-liner (which sets IRQF_NO_THREAD) was what Crystal originally
proposed:

https://lore.kernel.org/r/20250902224441.368483-1-crwood@redhat.com/

I guess your point is that handling the few operations in aer_irq()
in hard interrupt context is cheaper than waking a thread and
deferring them to that thread?

Intuitively I would assume that most threaded interrupt handlers
are architected in this way:  They only do minimal work in hard
interrupt context and defer the actual work to the (secondary)
thread.  E.g. pciehp_isr() + pciehp_ist() is likewise designed
to follow this principle.

Your research that at first glance, at least 21 of 40 instances of
request_threaded_irq() could just use IRQF_NO_THREAD, seems to
support the notion that the majority of interrupt handlers only
do minimal work in hard interrupt context.

But if that is the case, and if you believe that deferring that
small amount of work to a thread is nonsensical, then why is the
primary handler forced into a thread by default in the first place,
requiring drivers to explicitly opt out by setting IRQF_NO_THREAD?

Shouldn't it rather be the other way round, i.e. by default the
primary handler is *not* forced into a thread, but only if the
driver explicitly opts in?  (In cases where the primary handler
does a sufficient amount of work that is justified to be deferred
to a thread.)

Thanks,

Lukas