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

On Mon, Aug 24, 2026 at 05:57:48PM +0100, Ada Couprie Diaz wrote:
> Sorry for the delay, I did not manage to respond before going on leave
> as I got lost in the weeds of understanding what ptrace is doing when
> using hardware debug registers.

No worries, and welcome back!

> On 22/07/2026 22:42, Will Deacon wrote:
> > 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].
> I am indeed handling weird edge-cases !
> As Perf only uses local_irq masks, it is not sufficient to prevent us from
> taking
> debug exceptions while it manipulates the debug registers, so even if all
> the
> debug exceptions themselves are safe, perf/ptrace callbacks and syscalls are
> not.

Sorry, I was specifically thinking about the perf hw_breakpoint code invoked
off the back of the debug exception.

> > > 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. [...]
> > 
> If you both think that makes sense to save/restore DAIF here, I am
> happy to send a patch doing so. That would indeed make sure we
> don't hit this kind of issues !

I think that makes sense.

> Making the debug code safe from instrumentation is a different story...

Yeah, same with a bunch of the entry code tbh...

> > [...] 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/[email protected]
> I did not have the time to take a proper look, but it seems that Sebastian
> has sent another patch for this issue which keeps premption disabled :
> 
> https://lore.kernel.org/r/[email protected]
> 
> So I think we should be OK masking DAIF here then.

Oh, great!

Will