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

[Will Deacon]

On Wed, Jul 22, 2026 at 01:56:44PM +0100, Mark Rutland wrote:
> 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?

Yes, I think that's the only option, really, and I think we might even
have done that at some point in the past. The problem, however, is if we
end up getting preempted in that state. We currently have preemption
disabled, but there's a thread trying to change that based on one of
Ada's tests (not blaming the test, it's pointing out a real issue here):

https://lore.kernel.org/r/20260519222524.886454-1-longman@redhat.com

Will