Re: [PATCH 0/2] arm64/debug: clean up some HW BP edge cases

[Mark Rutland <mark.rutland@arm.com>]

On Wed, Jul 22, 2026 at 12:30:34PM +0100, Will Deacon wrote:
> On Wed, May 27, 2026 at 05:15:51PM +0100, Ada Couprie Diaz wrote:
> > This is a small series focused on fixing some unsoundess and edge case
> > related to hardware breakpoints and watchpoints.
> > 
> > It is motivated in part by the recent discussion on the
> > FEAT_Debugv8p6 series[0][1] regarding unclear guarantees on interruptions.
> > 
> > It doesn't address the issue of instrumentation, as NO_KPROBE is not
> > sufficient to prevent it (specifically ftrace) and would require a pass
> > over the whole debug handling code.
> > 
> > The bugs themselves are very much of the self-inflicted
> > "you should not be doing this" kind and not urgent, but it does solve
> > some of the questions on the FEAT_Dbugv8p6 series.
> > 
> > Most of the raw additions are comments trying to give more context to
> > understand `hw_breakpoint_thread_switch()`.
> 
> Hmm. From what I can tell, these patches are trying to handle various
> cases where we take a debug exception while executing the hw_breakpoint
> code itself. Even with these two fixes, is perf expecting to handle that
> sort of thing? I think it would be a lot more robust if we just prevented
> this from happening in the first place, similarly to the discussion from
> the other day around kprobes [2].

Since [2] mentions noinstr, it's worth noting that noinstr alone isn't
sufficient. Watchpoints also use this path, and we can't practically
filter watchpoint addresses to avoid hitting a watchpoint here.

I assume you'd be happy with masking debug exceptions entirely?

Mark.

> Will
> 
> [2] https://lore.kernel.org/all/alpuL10h7-OK2hFb@willie-the-truck/