Re: [PATCH 6/7] Input: gscps2 - serialize concurrent interrupt handlers
From: sashiko-bot@kernel.org
Date: 2026-08-30 21:07:20
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 [off-list ref] 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.
quoted hunk ↗ jump to hunk
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
[ ... ]
quoted hunk ↗ jump to hunk
@@ -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