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

[Russell King]

On Tue, Sep 08, 2026 at 11:38:26AM +0200, Sebastian Andrzej Siewior wrote:
> 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.

Yes, architecturally, when the CPU enters an exception handler,
interrupts are disabled by the CPU. However, that doesn't translate
to "the kernel runs with interrupts disabled". In most cases, we
re-enable interrupts if the exception comes from userspace.

However, I have no idea where in the call path is between the
exception being entered and the code you have a problem with - and
I've now forgotten where to find the call path, and I don't have
time to find it again. You are making this incredibly difficult,
and I don't have time for this. Sorry, this is my last reply for
a while, because this is just too much stress at this time for me.

What was a simple request has turned into a major source of frustration.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!