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

[Lukas Wunner <lukas@wunner.de>]

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