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

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

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