Re: [PATCH] Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: 2025-05-27 14:42:08
Also in:
linux-rt-devel, lkml
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: 2025-05-27 14:42:08
Also in:
linux-rt-devel, lkml
On 2025-05-27 15:36:37 [+0200], Gatien CHEVALLIER wrote:
Hello Sebastian,
Hello Gatien,
Can you elaborate on "This flag change makes not difference on !PREEMPT_RT" please? IIUC,this makes the callback not run in hard IRQ context, even in !PREEMPT_RT, no?
If you set - HRTIMER_MODE_REL_HARD then the callback runs in - hardirq context on !PREEMPT_RT - hardirq context on PREEMPT_RT. - HRTIMER_MODE_REL then the callback runs in - hardirq context on !PREEMPT_RT - preemptible softirq on PREEMPT_RT. - HRTIMER_MODE_REL_SOFT then the callback runs in - softirq context on !PREEMPT_RT - preemptible softirq on PREEMPT_RT. Therefore if you switch HRTIMER_MODE_REL_HARD -> HRTIMER_MODE_REL then it is a nop on !PREEMPT_RT.
Regarding the need of the spin_lock: gpio_keys_irq_timer() and gpio_keys_irq_isr() appear to access the same resources. Can't we have a concurrent access on it from: HR timer interrupt // GPIO interrupt?
Yes, it could.
But looking back at the patch, this situation does not depend on the HRTIMER_MODE_REL_HARD flag. So maybe it should be addressed separately.
Yes, please.
On the other hand, I should use the new guard(spinlock_irqsave)(&bdata->lock);
Yes, please. The other instance already does so. Sebastian