[PATCH] arm64/entry: Don't disable preemption in debug_exception_enter() with RT kernel

[PATCH] arm64/entry: Don't disable preemption in debug_exception_enter() with RT kernel

[Waiman Long]

Commit d8bb6718c4db ("arm64: Make debug exception handlers visible from
RCU") introduces debug_exception_enter() and debug_exception_exit()
where preemption is explicitly disabled. With a PREEMPT_RT debug kernel,
the following bug report can happen.

  BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 15255, name: gdb_app
  preempt_count: 1, expected: 0
  RCU nest depth: 0, expected: 0
  1 lock held by gdb_app/15255:
  #0: ffff10007f41b7d8 (&sighand->siglock){..}-{3:3}, at: force_sig_info_to_task+0x34/0x130
  Preemption disabled at:
  [<ffff800080081ea8>] debug_exception_enter+0x18/0x70
    :
  Call trace:
  dump_backtrace+0xac/0x130
  show_stack+0x1c/0x24
  dump_stack_lvl+0xa0/0xe0
  dump_stack+0x14/0x2c
  __might_resched+0x178/0x230
  rt_spin_lock+0x58/0x120
  force_sig_info_to_task+0x34/0x130
  force_sig_fault+0x58/0x80
  arm64_force_sig_fault+0x44/0x70
  send_user_sigtrap+0x5c/0xa0
  brk_handler+0x38/0x5c
  do_debug_exception+0x78/0x110
  el0_dbg+0x50/0x1e0
  el0t_64_sync_handler+0x114/0x150
  el0t_64_sync+0x17c/0x180

Fix that by blocking the preempt_disable()/preempt_enable_no_resched()
calls when CONFIG_PREEMPT_RT is enabled.

Signed-off-by: Waiman Long <longman@redhat.com>
---
 arch/arm64/kernel/entry-common.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
index c7a23f7c2212..191441b22b7c 100644
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -290,15 +290,17 @@ static __always_inline void fpsimd_syscall_exit(void)
 }
 
 /*
- * In debug exception context, we explicitly disable preemption despite
- * having interrupts disabled.
+ * In debug exception context, we explicitly disable preemption except for
+ * PREEMPT_RT kernel as rt_spin_lock() can be called.
+ *
  * This serves two purposes: it makes it much less likely that we would
  * accidentally schedule in exception context and it will force a warning
  * if we somehow manage to schedule by accident.
  */
 static void debug_exception_enter(struct pt_regs *regs)
 {
-	preempt_disable();
+	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+		preempt_disable();
 
 	/* This code is a bit fragile.  Test it. */
 	RCU_LOCKDEP_WARN(!rcu_is_watching(), "exception_enter didn't work");
@@ -307,7 +309,8 @@ NOKPROBE_SYMBOL(debug_exception_enter);
 
 static void debug_exception_exit(struct pt_regs *regs)
 {
-	preempt_enable_no_resched();
+	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+		preempt_enable_no_resched();
 }
 NOKPROBE_SYMBOL(debug_exception_exit);
 
-- 
2.54.0

Re: [PATCH] arm64/entry: Don't disable preemption in debug_exception_enter() with RT kernel

[Luis Claudio R. Goncalves]

On Tue, May 19, 2026 at 06:25:24PM -0400, Waiman Long wrote:
> Commit d8bb6718c4db ("arm64: Make debug exception handlers visible from
> RCU") introduces debug_exception_enter() and debug_exception_exit()
> where preemption is explicitly disabled. With a PREEMPT_RT debug kernel,
> the following bug report can happen.
> 
>   BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
>   in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 15255, name: gdb_app
>   preempt_count: 1, expected: 0
>   RCU nest depth: 0, expected: 0
>   1 lock held by gdb_app/15255:
>   #0: ffff10007f41b7d8 (&sighand->siglock){..}-{3:3}, at: force_sig_info_to_task+0x34/0x130
>   Preemption disabled at:
>   [<ffff800080081ea8>] debug_exception_enter+0x18/0x70
>     :
>   Call trace:
>   dump_backtrace+0xac/0x130
>   show_stack+0x1c/0x24
>   dump_stack_lvl+0xa0/0xe0
>   dump_stack+0x14/0x2c
>   __might_resched+0x178/0x230
>   rt_spin_lock+0x58/0x120
>   force_sig_info_to_task+0x34/0x130
>   force_sig_fault+0x58/0x80
>   arm64_force_sig_fault+0x44/0x70
>   send_user_sigtrap+0x5c/0xa0
>   brk_handler+0x38/0x5c
>   do_debug_exception+0x78/0x110
>   el0_dbg+0x50/0x1e0
>   el0t_64_sync_handler+0x114/0x150
>   el0t_64_sync+0x17c/0x180
> 
> Fix that by blocking the preempt_disable()/preempt_enable_no_resched()
> calls when CONFIG_PREEMPT_RT is enabled.

Hi Waiman!

Last year Ada Couprie Diaz wrote a patcheseries that enhanced greatly the
ARM64 debug exception code. In the cover letter there is a discussion about
the effect of the patches on RT[0] (look for PREEMPT_RT), explaining that
there are a few remaining known bugs and briefly discussing the best way to
fix then. There is also a discussion[1] about the specific issue you reported.

I took the liberty of adding Ada to the thread.

Best regards,
Luis

[0] https://lore.kernel.org/all/20250707114109.35672-1-ada.coupriediaz@arm.com/
[1] https://lore.kernel.org/linux-arm-kernel/e86c5c3a-6666-46a7-b7ec-e803212a81a1@arm.com/
 
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
>  arch/arm64/kernel/entry-common.c | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> index c7a23f7c2212..191441b22b7c 100644
> --- a/arch/arm64/kernel/entry-common.c
> +++ b/arch/arm64/kernel/entry-common.c
> @@ -290,15 +290,17 @@ static __always_inline void fpsimd_syscall_exit(void)
>  }
>  
>  /*
> - * In debug exception context, we explicitly disable preemption despite
> - * having interrupts disabled.
> + * In debug exception context, we explicitly disable preemption except for
> + * PREEMPT_RT kernel as rt_spin_lock() can be called.
> + *
>   * This serves two purposes: it makes it much less likely that we would
>   * accidentally schedule in exception context and it will force a warning
>   * if we somehow manage to schedule by accident.
>   */
>  static void debug_exception_enter(struct pt_regs *regs)
>  {
> -	preempt_disable();
> +	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
> +		preempt_disable();
>  
>  	/* This code is a bit fragile.  Test it. */
>  	RCU_LOCKDEP_WARN(!rcu_is_watching(), "exception_enter didn't work");
> @@ -307,7 +309,8 @@ NOKPROBE_SYMBOL(debug_exception_enter);
>  
>  static void debug_exception_exit(struct pt_regs *regs)
>  {
> -	preempt_enable_no_resched();
> +	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
> +		preempt_enable_no_resched();
>  }
>  NOKPROBE_SYMBOL(debug_exception_exit);
>  
> -- 
> 2.54.0
> 
> 
---end quoted text---

Re: [PATCH] arm64/entry: Don't disable preemption in debug_exception_enter() with RT kernel

[Sebastian Andrzej Siewior]

On 2026-05-19 18:25:24 [-0400], Waiman Long wrote:
> Commit d8bb6718c4db ("arm64: Make debug exception handlers visible from
> RCU") introduces debug_exception_enter() and debug_exception_exit()
> where preemption is explicitly disabled. With a PREEMPT_RT debug kernel,
> the following bug report can happen.
…

What kernel is this? I have backport (which is being tested) for v6.6
and v6.12, the patches are from v6.17-rc1.

Sebastian

Re: [PATCH] arm64/entry: Don't disable preemption in debug_exception_enter() with RT kernel

[Luis Claudio R. Goncalves]

On Wed, May 20, 2026 at 08:19:20AM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-05-19 18:25:24 [-0400], Waiman Long wrote:
> > Commit d8bb6718c4db ("arm64: Make debug exception handlers visible from
> > RCU") introduces debug_exception_enter() and debug_exception_exit()
> > where preemption is explicitly disabled. With a PREEMPT_RT debug kernel,
> > the following bug report can happen.
> …
> 
> What kernel is this? I have backport (which is being tested) for v6.6
> and v6.12, the patches are from v6.17-rc1.

Sebastian, hardware breakpoint and watchpoint handlers still call
debug_exception_exit() and disable preemption on aarch64. That should
happen on v7.1-rc4 indeed. The suggestion was to mimic what x86_64 does
with notify_die() -> hw_breakpoint_exceptions_notify(). In ARM
hw_breakpoint_exceptions_notify() is a stub that always returns
NOTIFY_DONE.

Luis

> Sebastian
> 
---end quoted text---

Re: [PATCH] arm64/entry: Don't disable preemption in debug_exception_enter() with RT kernel

[Luis Claudio R. Goncalves]

On Wed, May 20, 2026 at 08:19:20AM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-05-19 18:25:24 [-0400], Waiman Long wrote:
> > Commit d8bb6718c4db ("arm64: Make debug exception handlers visible from
> > RCU") introduces debug_exception_enter() and debug_exception_exit()
> > where preemption is explicitly disabled. With a PREEMPT_RT debug kernel,
> > the following bug report can happen.
> …
> 
> What kernel is this? I have backport (which is being tested) for v6.6
> and v6.12, the patches are from v6.17-rc1.

Sebastian, hardware breakpoint and watchpoint handlers still call
debug_exception_exit() and disable preemption on aarch64. That should
happen on v7.1-rc4 indeed. The suggestion was to mimic what x86_64 does
with notify_die() -> hw_breakpoint_exceptions_notify(). In ARM
hw_breakpoint_exceptions_notify() is a stub that always returns
NOTIFY_DONE.

Luis

> Sebastian
> 
---end quoted text---

Re: [PATCH] arm64/entry: Don't disable preemption in debug_exception_enter() with RT kernel

[Waiman Long]

On 5/20/26 2:19 AM, Sebastian Andrzej Siewior wrote:
> On 2026-05-19 18:25:24 [-0400], Waiman Long wrote:
>> Commit d8bb6718c4db ("arm64: Make debug exception handlers visible from
>> RCU") introduces debug_exception_enter() and debug_exception_exit()
>> where preemption is explicitly disabled. With a PREEMPT_RT debug kernel,
>> the following bug report can happen.
> …
>
> What kernel is this? I have backport (which is being tested) for v6.6
> and v6.12, the patches are from v6.17-rc1.

The kernel backtrace is produced using the latest v7.1-rc4 kernel. There 
are a number of changes to the debug_exception_enter() and 
debug_exception_exit() functions over the years, but the preemption 
disable code remains since its introduction in v5.3.

BTW, what v6.17-rc1 patches are you talking about?

-Longman

Re: [PATCH] arm64/entry: Don't disable preemption in debug_exception_enter() with RT kernel

[Sebastian Andrzej Siewior]

On 2026-05-20 17:01:00 [-0400], Waiman Long wrote:
> 
> On 5/20/26 2:19 AM, Sebastian Andrzej Siewior wrote:
> > On 2026-05-19 18:25:24 [-0400], Waiman Long wrote:
> > > Commit d8bb6718c4db ("arm64: Make debug exception handlers visible from
> > > RCU") introduces debug_exception_enter() and debug_exception_exit()
> > > where preemption is explicitly disabled. With a PREEMPT_RT debug kernel,
> > > the following bug report can happen.
> > …
> > 
> > What kernel is this? I have backport (which is being tested) for v6.6
> > and v6.12, the patches are from v6.17-rc1.
> 
> The kernel backtrace is produced using the latest v7.1-rc4 kernel. There are
> a number of changes to the debug_exception_enter() and
> debug_exception_exit() functions over the years, but the preemption disable
> code remains since its introduction in v5.3.

Let me look at this again.

> BTW, what v6.17-rc1 patches are you talking about?

https://lore.kernel.org/all/20260528144825.850351-1-bigeasy@linutronix.de/

> -Longman

Sebastian

Re: [PATCH] arm64/entry: Don't disable preemption in debug_exception_enter() with RT kernel

[Sebastian Andrzej Siewior]

On 2026-05-28 16:51:24 [+0200], To Waiman Long wrote:
> > The kernel backtrace is produced using the latest v7.1-rc4 kernel. There are
> > a number of changes to the debug_exception_enter() and
> > debug_exception_exit() functions over the years, but the preemption disable
> > code remains since its introduction in v5.3.
> 
> Let me look at this again.

So how do you reproduce this? The calls within debug_exception_enter()/
exit() look harmless or I miss the big thing here.
From your backtrace, you have brk_handler() and this is gone since
commit 31575e11ecf7e ("arm64: debug: split brk64 exception entry") which
is v6.17-rc1. I can use gdb with breakpoint handling.

Sebastian

Re: [PATCH] arm64/entry: Don't disable preemption in debug_exception_enter() with RT kernel

[Luis Claudio R. Goncalves]

On Thu, May 28, 2026 at 05:35:54PM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-05-28 16:51:24 [+0200], To Waiman Long wrote:
> > > The kernel backtrace is produced using the latest v7.1-rc4 kernel. There are
> > > a number of changes to the debug_exception_enter() and
> > > debug_exception_exit() functions over the years, but the preemption disable
> > > code remains since its introduction in v5.3.
> > 
> > Let me look at this again.
> 
> So how do you reproduce this? The calls within debug_exception_enter()/
> exit() look harmless or I miss the big thing here.
> From your backtrace, you have brk_handler() and this is gone since
> commit 31575e11ecf7e ("arm64: debug: split brk64 exception entry") which
> is v6.17-rc1. I can use gdb with breakpoint handling.

Sebastian, in the original series Ada provided a few tests, including the
two files I list below. Running that test in a v7.1-rc5 kernel with
PREEMPT_RT and DEBUG_ATOMIC_SLEEP enabled, I get this backtrace:

[10416.818417] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
[10416.818426] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 6437, name: gdb_prog1
[10416.818428] preempt_count: 1, expected: 0
[10416.818430] RCU nest depth: 1, expected: 1
[10416.818434] CPU: 11 UID: 0 PID: 6437 Comm: gdb_prog1 Not tainted 7.1.0-rc5-rt1 #2 PREEMPT_{RT,(full)} 
[10416.818437] Hardware name: Lenovo HR330A            7X33CTO1WW    /FALCON     , BIOS hve104r-1.15 02/26/2021
[10416.818440] Call trace:
[10416.818442]  show_stack+0x20/0x40 (C)
[10416.818450]  dump_stack_lvl+0x88/0xb8
[10416.818454]  dump_stack+0x18/0x30
[10416.818457]  __might_resched+0x18c/0x1c8
[10416.818462]  rt_spin_lock+0x4c/0x1b0
[10416.818467]  force_sig_info_to_task+0x34/0x1f0
[10416.818471]  force_sig_fault+0x68/0xb0
[10416.818473]  arm64_force_sig_fault+0x44/0x70
[10416.818476]  ptrace_hbptriggered+0xd0/0x150
[10416.818479]  __perf_event_overflow+0xf4/0x300
[10416.818483]  perf_swevent_event+0x1b8/0x1f0
[10416.818486]  perf_bp_event+0xcc/0xe0
[10416.818489]  do_breakpoint+0xf4/0x238
[10416.818493]  el0_breakpt+0x7c/0x200
[10416.818497]  el0t_64_sync_handler+0xa8/0xf0
[10416.818500]  el0t_64_sync+0x1b0/0x1b8


n order to run the test, you need to create two files with the names and
content listed below and run the following commands:

    cc gdb_prog1.c -o gdb_prog1 -O0 -g
    gdb -x gdb_cmdlist ./gdb_prog1

That's it.

The files I mentioned are:

===== gdb_cmdlist 

---------- >8 cut here 8< ----------
start
hbreak 3
watch target
commands 2
continue
end
commands 3
continue
end
continue
jump 11
continue
quit
---------- >8 cut here 8< ----------


===== gdb_prog1.c

---------- >8 cut here 8< ----------
int main() {
	int add = 0xAA;
	int target = 0;

	target += add;

#ifdef COMPAT
    __asm__("BKPT");
#else
    __asm__("BRK 1");
#endif

	return target;
}
---------- >8 cut here 8< ----------

Luis