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

[Sebastian Andrzej Siewior]

On 2026-09-08 09:43:43 [+0100], Russell King wrote:
> > > > The linked report shows a backtrace by "BUG: sleeping function"
> > > > originating from el0_breakpt() -> perf_bp_event() following by sending a
> > > > signal force_sig_fault() followed by rt_spin_lock() and
> > > > __might_resched(). It also contains a reproducer.
> > > > 
> > > > The first sentence has the part
> > > > | The hardware event is
> > > > | delivered with disabled interrupts and perf intrastrucure expects
> > > > | disabled interrupts while the overflow callback is invoked.
> > > 
> > > *Where* are interrupts disabled?
> > 
> > On exception entry point, that would el0t_64_sync() for arm64 as in the
> > report.
> 
> Oh FFS. So why does this need to be done on ARM? Explain it. This is
> what I'm trying to get out of you, but you're being very resistant
> to providing the technical details. I can only think you haven't
> actually done the analysis.

I had the feeling that this is not what you were expecting but I wasn't
sure what you were expecting either.

The hardware breakpoint is delivered to the OS via an exception and on
exception entry point the interrupts are disabled. This isn't unique to
ARM but the same on other architectures, too.
It is not limited to ARM but also Loongarch which is sending a signal in
its handler (the one registered via register_user_hw_breakpoint()).
It is not an issue on X86 because they don't send signal but just toggle
the DR6 register.
powerpc and sh have different logic where the perf event is disabled
without sending a signal.
xtensa is the only one untouched which does send a signal from the
hw-breakpoint handler but xtensa does not support PREEMPT_RT and
therefore doesn't enforce proper lock nesting (so this is likely not the
only issue).

> So, NAK.

Would you reconsider, please? It does not seem justified.

Sebastian