Re: [PATCH 6/7] Input: gscps2 - serialize concurrent interrupt handlers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Returning IRQ_NONE on lock contention in a shared hardware interrupt handler fails to clear the hardware interrupt, causing a spurious interrupt storm that permanently disables the IRQ line.
--

commit f58a76b080709bfb3ea6255a5211466eb9b5af11
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: gscps2 - serialize concurrent interrupt handlers

This commit serializes executions of gscps2_interrupt() using a new
gscps2_interrupt_lock. It uses a trylock and returns IRQ_NONE when the lock
cannot be acquired to prevent overlapping executions and avoid recursive
deadlocks.

> diff --git a/drivers/input/serio/gscps2.c b/drivers/input/serio/gscps2.c
> index 907fb1537595c..2afd53a163ffa 100644
> --- a/drivers/input/serio/gscps2.c
> +++ b/drivers/input/serio/gscps2.c

[ ... ]

> @@ -305,21 +307,31 @@ static irqreturn_t gscps2_interrupt(int irq, void *dev)
>  {
>  	struct gscps2port *ps2port;
>  	bool handled = false;
> +	bool more_data;
> +
> +	ACQUIRE(spinlock_irqsave_try, lock)(&gscps2_interrupt_lock);
> +	if (ACQUIRE_ERR(spinlock_irqsave_try, &lock))
> +		return IRQ_NONE;

[Severity: High]
Does returning IRQ_NONE on lock contention here fail to clear the hardware
interrupt, causing a spurious interrupt storm?

If CPU A calls gscps2_interrupt() manually (e.g., from gscps2_open()) and
acquires the lock:

CPU A
gscps2_interrupt()
    ACQUIRE(spinlock_irqsave_try, lock)(&gscps2_interrupt_lock); // succeeds

And concurrently, new data arrives causing a hardware interrupt on CPU B:

CPU B (Hardware Interrupt)
gscps2_interrupt()
    ACQUIRE(spinlock_irqsave_try, lock)(&gscps2_interrupt_lock); // fails
    return IRQ_NONE;

Because the interrupt is level-triggered and the source was not cleared, won't
the interrupt controller immediately re-assert the IRQ on CPU B as soon as the
handler returns?

This could trap CPU B in a tight interrupt storm loop. If CPU A takes
significant time in serio_interrupt() (e.g., due to input subsystem lock
contention or console writes), could the storm exceed the kernel's unhandled
interrupt threshold and permanently disable the shared IRQ line?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260830-gscps2-v1-0-c733d4cae7f9@gmail.com?part=6