Re: [RFC v3 2/2] arm64: kprobes: Allow reentering kprobes while single-stepping

[Pu Hu]

On 7/16/2026 9:24 PM, Will Deacon wrote:
> On Fri, Jul 10, 2026 at 06:32:55AM +0000, Pu Hu wrote:
>> From: Pu Hu <hupu@xxxxxxxxxxxxx>
>>
>> A kprobe can be hit while another kprobe is in KPROBE_HIT_SS state. This
>> can happen when tracing or perf code runs from the debug exception path
>> while the first kprobe is preparing or executing its out-of-line
>> single-step instruction.
> 
> I don't understand this part. The single-step runs with debug exceptions
> disabled (kprobes_save_local_irqflag() sets PSTATE.D) so how do we end
> up taking one?
> 
> Will

Hi Will,

Thanks for looking at this.

You are right that the single-step runs with debug exceptions disabled.
However, the case I was referring to is not a hardware breakpoint or a
software-step exception, but another Breakpoint Instruction exception
generated by executing a BRK instruction. A BRK instruction exception is 
not masked by PSTATE.D, so it can still be taken while handling a kprobe.

As far as I understand the architecture, there are two different cases here:

   - Breakpoint Instruction exceptions, generated by executing a BRK
     instruction.
   - Breakpoint exceptions, generated by the debug logic, for example by
     programmed breakpoint registers.

PSTATE.D masks debug exceptions such as hardware breakpoints, 
watchpoints and software-step exceptions, but it does not mask 
Breakpoint Instruction exceptions generated by BRK. This also seems 
consistent with the pseudocode for BRK, 
Arch64.SoftwareBreakpoint(imm16), which does not appear to check 
PSTATE.D before taking the exception.

Therefore, even if kprobes_save_local_irqflag() sets PSTATE.D while 
handling the first kprobe, if the code executed from that path reaches 
another instruction patched with BRK, it can still take a Breakpoint 
Instruction exception. In other words, the nested case I mentioned is 
another kprobe BRK being hit, not a hardware debug exception or a 
software-step exception.

The above analysis is based on the Arm Architecture Reference Manual,
including the descriptions of BRK, Breakpoint Instruction exceptions and
Breakpoint exceptions.

Thanks,
Pu Hu