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

["Luis Claudio R. Goncalves" <lgoncalv@redhat.com>]

On Fri, Aug 14, 2026 at 11:20:49AM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-08-14 09:03:03 [+0000], sashiko-bot@kernel.org wrote:
> > > +	if (xchg_relaxed(&bp->hw.arch_hw_notif_busy, 1) ||
> > > +	    WARN_ON_ONCE(task_work_add(current, &bp->hw.arch_hw_notif, TWA_RESUME)))
> > [Severity: High]
> > Will using TWA_RESUME here cause a hang if a hardware watchpoint is triggered
> > during a blocking syscall like futex() or read()?
> > 
> > When a blocking syscall accesses watched memory (e.g., via get_user()), the
> > watchpoint synchronously triggers and queues the SIGTRAP task work via
> > task_work_add(). Since TWA_RESUME only sets TIF_NOTIFY_RESUME, and
> > signal_pending() ignores TIF_NOTIFY_RESUME, the syscall wait loop will not
> > abort. 
> > 
> > Does this need to use TWA_SIGNAL instead so that TIF_NOTIFY_SIGNAL is set and
> > the interruptible sleep correctly aborts to deliver the pending task work?
> 
> Well, this only means that the signal will be delivered once the syscall
> handling is complete. I don't see a reason why the syscall should be
> interrupted just to deliver the signal right away. The logic should not
> be affected by delivering the signal immediately.
> 
> > > +		put_event(bp);
> > > +}
> > > +#endif

Sebastian, do you intend to perform any extra work on this patch or is it
ready for consumption? I have been using this change in test kernels for a
while now and haven't had a single problem so far.

Best,
Luis

> Sebastian
> 
---end quoted text---