From a92c4db4f3ed2e3008f12aa5058839ea40ec3151 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Thu, 24 Jul 2025 09:13:04 +0200 Subject: [PATCH] 5.15-stable patches added patches: input-gpio-keys-fix-a-sleep-while-atomic-with-preempt_rt.patch --- ...a-sleep-while-atomic-with-preempt_rt.patch | 68 +++++++++++++++++++ queue-5.15/series | 1 + 2 files changed, 69 insertions(+) create mode 100644 queue-5.15/input-gpio-keys-fix-a-sleep-while-atomic-with-preempt_rt.patch diff --git a/queue-5.15/input-gpio-keys-fix-a-sleep-while-atomic-with-preempt_rt.patch b/queue-5.15/input-gpio-keys-fix-a-sleep-while-atomic-with-preempt_rt.patch new file mode 100644 index 0000000000..dc6887e69b --- /dev/null +++ b/queue-5.15/input-gpio-keys-fix-a-sleep-while-atomic-with-preempt_rt.patch @@ -0,0 +1,68 @@ +From f4a8f561d08e39f7833d4a278ebfb12a41eef15f Mon Sep 17 00:00:00 2001 +From: Fabrice Gasnier +Date: Fri, 30 May 2025 15:36:43 -0700 +Subject: Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT + +From: Fabrice Gasnier + +commit f4a8f561d08e39f7833d4a278ebfb12a41eef15f upstream. + +When enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs in +hard irq context, but the input_event() takes a spin_lock, which isn't +allowed there as it is converted to a rt_spin_lock(). + +[ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 +[ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0 +... +[ 4054.290195] __might_resched+0x13c/0x1f4 +[ 4054.290209] rt_spin_lock+0x54/0x11c +[ 4054.290219] input_event+0x48/0x80 +[ 4054.290230] gpio_keys_irq_timer+0x4c/0x78 +[ 4054.290243] __hrtimer_run_queues+0x1a4/0x438 +[ 4054.290257] hrtimer_interrupt+0xe4/0x240 +[ 4054.290269] arch_timer_handler_phys+0x2c/0x44 +[ 4054.290283] handle_percpu_devid_irq+0x8c/0x14c +[ 4054.290297] handle_irq_desc+0x40/0x58 +[ 4054.290307] generic_handle_domain_irq+0x1c/0x28 +[ 4054.290316] gic_handle_irq+0x44/0xcc + +Considering the gpio_keys_irq_isr() can run in any context, e.g. it can +be threaded, it seems there's no point in requesting the timer isr to +run in hard irq context. + +Relax the hrtimer not to use the hard context. + +Fixes: 019002f20cb5 ("Input: gpio-keys - use hrtimer for release timer") +Suggested-by: Sebastian Andrzej Siewior +Signed-off-by: Fabrice Gasnier +Signed-off-by: Gatien Chevallier +Link: https://lore.kernel.org/r/20250528-gpio_keys_preempt_rt-v2-1-3fc55a9c3619@foss.st.com +Cc: stable@vger.kernel.org +Signed-off-by: Dmitry Torokhov +[ adjusted context ] +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + drivers/input/keyboard/gpio_keys.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/input/keyboard/gpio_keys.c ++++ b/drivers/input/keyboard/gpio_keys.c +@@ -493,7 +493,7 @@ static irqreturn_t gpio_keys_irq_isr(int + if (bdata->release_delay) + hrtimer_start(&bdata->release_timer, + ms_to_ktime(bdata->release_delay), +- HRTIMER_MODE_REL_HARD); ++ HRTIMER_MODE_REL); + out: + spin_unlock_irqrestore(&bdata->lock, flags); + return IRQ_HANDLED; +@@ -633,7 +633,7 @@ static int gpio_keys_setup_key(struct pl + + bdata->release_delay = button->debounce_interval; + hrtimer_init(&bdata->release_timer, +- CLOCK_REALTIME, HRTIMER_MODE_REL_HARD); ++ CLOCK_REALTIME, HRTIMER_MODE_REL); + bdata->release_timer.function = gpio_keys_irq_timer; + + isr = gpio_keys_irq_isr; diff --git a/queue-5.15/series b/queue-5.15/series index 2053000fb6..300ef95376 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -73,3 +73,4 @@ x86-fix-get_wchan-to-support-the-orc-unwinder.patch sched-add-wrapper-for-get_wchan-to-keep-task-blocked.patch x86-fix-__get_wchan-for-stacktrace.patch x86-pin-task-stack-in-__get_wchan.patch +input-gpio-keys-fix-a-sleep-while-atomic-with-preempt_rt.patch -- 2.47.2