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

[Russell King <linux@armlinux.org.uk>]

On Tue, Sep 08, 2026 at 10:37:40AM +0200, Sebastian Andrzej Siewior wrote:
> 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@armlinux.org.uk> 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.

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.

So, NAK.

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