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

[Sebastian Andrzej Siewior]

On 2026-09-08 09:00:04 [+0100], Russell King wrote:
> On Tue, Sep 08, 2026 at 09:54:55AM +0200, Sebastian Andrzej Siewior wrote:
> > On 2026-09-07 15:46:09 [+0100], Russell King wrote:
> > > On Fri, Sep 04, 2026 at 05:54:04PM +0200, Sebastian Andrzej Siewior wrote:
> > > > On 2026-09-03 13:31:46 [-0400], Steven Rostedt wrote:
> > > > > On Thu, 3 Sep 2026 17:47:24 +0100
> > > > > Russell King <linux@xxxxxxxxxxxxxxx> wrote:
> > > > > 
> > > > > > What do you expect to happen with this? Which arch maintainer should
> > > > > > apply this patch that affects three different independently maintained
> > > > > > architectures?
> > > > 
> > > > Well, if you as the ARM person are fine with ARM part, an ACK would be
> > > > appreciated. If you have something to object, it would be nice to let me
> > > > know so I can adjust accordingly.
> > > 
> > > First, I only just looked at the email - you may have noticed I'm not
> > > very active with the kernel anymore, as I'm a full-time carer at the
> > > moment.
> > > 
> > > Second, I'm not fine with the patch as-is, because it's not clear how
> > > it could be merged in its current form. It would be inappropriate to
> > > give an Ack, because an Ack means I'm fine with it. I'm not.
> > > 
> > > Third, I haven't actually reviewed the patch itself (see first point).
> > > 
> > > Looking deeper now, I see nothing in the linked report, nor in your
> > > write-up that identifies what is responsible for the context being
> > > inappropriate to deliver the SIGTRAP. See the first point - I'm not
> > 
> > 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.

Sebastian