On 7/16/2026 9:24 PM, Will Deacon wrote:

On Fri, Jul 10, 2026 at 06:32:55AM +0000, Pu Hu wrote:

quoted

From: Pu Hu <redacted>

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