Re: [PATCH] genirq: Resend pending interrupts after handle_simple_irq()

[Marc Zyngier]

On Sun, 01 Nov 2026 04:56:28 +0000,
Avi Weiss <thnkslprpt@xxxxxxxxx> wrote:
> 
> Commit 2c9e7f857400 ("genirq: Teach handle_simple_irq() to resend an
> in-progress interrupt") records a concurrent interrupt as IRQS_PENDING
> when another CPU is still handling the IRQ. However, handle_simple_irq()
> does not consume the pending state after the first handler completes,
> so an interrupt arriving during an affinity change can be lost.
>

This commit message isn't quite accurate.

"Consuming" has a particular meaning for edge-triggered interrupts,
and indicates that the interrupt is not pending anymore. Here, the bug
is that we don't check for the race after the initial handling, and
while the interrupt is still pending (hence not really lost), the
signalling is the missing part.

> Check IRQS_PENDING after handle_irq_event() and request a resend, as
> handle_fasteoi_irq() already does.

And then this sentence makes perfect sense.

> 
> Fixes: 2c9e7f857400 ("genirq: Teach handle_simple_irq() to resend an in-progress interrupt")
> Signed-off-by: Avi Weiss <thnkslprpt@xxxxxxxxx>
> ---
> 
> Related 2025 patch/review: https://lore.kernel.org/r/20250708173404.1278635-2-maz@xxxxxxxxxx
>  kernel/irq/chip.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index de754db414d1..4a131dd72196 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -626,6 +626,8 @@ void handle_simple_irq(struct irq_desc *desc)
>  
>  	kstat_incr_irqs_this_cpu(desc);
>  	handle_irq_event(desc);
> +	if (unlikely(desc->istate & IRQS_PENDING))
> +		check_irq_resend(desc, false);
>  }
>  EXPORT_SYMBOL_GPL(handle_simple_irq);

Other than the nits above:

Reviewed-by: Marc Zyngier <maz@xxxxxxxxxx>

	M.

-- 
Without deviation from the norm, progress is not possible.