Re: [RFC PATCH] ARM, ARM64, LOONGARCH: Delay HW BP notification to task_work()

[Luis Claudio R. Goncalves]

On Mon, Jul 13, 2026 at 04:49:39PM +0200, Sebastian Andrzej Siewior wrote:
> Waiman, Luis, Ada reported that HW breakpoints on ARM64 trigger
> "sleeping while atomic" warnings on PREEMPT_RT. The hardware event is
> delivered with disabled interrupts and perf intrastrucure expects
> disabled interrupts while the overflow callback is invoked.
> 
> The callback then sends a SIGTRAP signal for which it acquires
> sighand_struct::siglock, a spinlock_t which becomes a sleeping lock and
> must not be acquired in atomic context.
> 
> Delay the event callback until the return to userland.
> Add perf_arch_hwbp_notify(), a generic perf callback which delayes the
> actual callback invocation to task_work_add() callback. This callback
> invokes the architecture defines callback arch_hwbp_send_sig().
> This requires struct callback_head and the functions require
> ARCH_NEED_PERF_HW_NOTIF to be defined.
> 
> This was reported against ARM64. ARM and LongARCH follow the same
> pattern are also converted.
> 
> Reported-by: Luis Claudio R. Goncalves <lgoncalv@xxxxxxxxxx>
> Reported-by: Waiman Long <longman@xxxxxxxxxx>
> Closes: https://lore.kernel.org/all/aho0eqjMESuHxECr@xxxxxxxxxx/
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
> ---
> 
> This is approximately the fifth iteration at which point I think I can
> share what I have.
> 
> Could this be tested, please? I tested it on arm64 for arm64 based on
> Luis' test. ARM compiles my HW lacks support for this I think (gdb
> aborts early). I hope the best for LoongARCH.

I tested your patch on baremetal (3 different aarch64 machines) and 3
different Virtual Machines. Apart from the one VM that didn't provide the
HW breakpoints the test used, I was able to reproduce the problem with
v7.2-rc5-rt3 and earlier kernels in all the other setups. Applying your
patch eliminated the backtraces. I ran several batches of 2000 and 10000
executions in a row of the gdb test from the original thread without a
glitch.

Having DEBUG_ATOMIC_SLEEP enabled in the kernel (along with PREEMPT_RT)
was all I needed to reproduce the problem with the unpatched kernel. After
I applied the patch I run tests with and without lockdep. No backtrace,
no complaints.

I started working on trying to reproduce the (possible) problem Sashiko
highlighted, but so far, no luck in reproducing that specific scenario.

Best regards,
Luis