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

Hi Will,

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.

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.
>> 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 !
Making the debug code safe from instrumentation is a different story...
> [...] 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.

Thanks both,
Ada