On 7/8/2026 8:54 AM, Masami Hiramatsu wrote: > On Mon, 6 Jul 2026 08:36:49 +0000 > Pu Hu <[email protected]> wrote: > >> From: Pu Hu <[email protected]> >> >> 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. >> >> Currently arm64 treats a kprobe hit in KPROBE_HIT_SS as unrecoverable, >> the same as a hit in KPROBE_REENTER. This is too strict. A hit in >> KPROBE_HIT_SS is still a one-level reentry and can be handled by saving >> the current kprobe state and setting up single-step for the new probe, >> just like reentry from KPROBE_HIT_ACTIVE or KPROBE_HIT_SSDONE. >> >> The truly unrecoverable case is hitting another kprobe while already in >> KPROBE_REENTER, because the reentry save area has already been consumed. >> >> Move KPROBE_HIT_SS to the recoverable reentry cases and leave >> KPROBE_REENTER as the unrecoverable nested reentry case. >> >> This mirrors the x86 fix in commit 6a5022a56ac3 >> ("kprobes/x86: Allow to handle reentered kprobe on single-stepping"). > > Can you also check the Sashiko comment? > > https://sashiko.dev/#/patchset/20260706083636.159883-1-hupu%40transsion.com?part=2 > > This seems indicating potentially brakage of reenter kprobes on arm64. > But is it possible to hit another kprobe while SS on arm64? It is > the same question about the previous one, can NMI happens during > the single stepping? (maybe yes, because it is non-maskable)
It is possible as this is what we hit. There are preempt_enable/disable() calls during SS which can trigger perf events sampling the user stack, which may then trigger page faults and send the CPU into one more level of exception context. I believe this is what you saw in 6a5022a56ac3? > Anyway, for making it safer, we need to add saved_irqflags to prev_kprobe. Yes, this seems to be a legit bug that needs to be fixed. Thank you. > Thank you, > >> >> Signed-off-by: Pu Hu <[email protected]> >> Signed-off-by: Hongyan Xia <[email protected]> >> --- >> arch/arm64/kernel/probes/kprobes.c | 8 +++++++- >> 1 file changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm64/kernel/probes/kprobes.c >> b/arch/arm64/kernel/probes/kprobes.c >> index e4d2852ce2fb..764b2228cca0 100644 >> --- a/arch/arm64/kernel/probes/kprobes.c >> +++ b/arch/arm64/kernel/probes/kprobes.c >> @@ -240,10 +240,16 @@ static int __kprobes reenter_kprobe(struct kprobe *p, >> switch (kcb->kprobe_status) { >> case KPROBE_HIT_SSDONE: >> case KPROBE_HIT_ACTIVE: >> + case KPROBE_HIT_SS: >> + /* >> + * A probe can be hit while another kprobe is preparing or >> + * executing its XOL single-step instruction. This is still a >> + * recoverable one-level reentry, so handle it in the same way >> as >> + * reentry from KPROBE_HIT_ACTIVE or KPROBE_HIT_SSDONE. >> + */ >> kprobes_inc_nmissed_count(p); >> setup_singlestep(p, regs, kcb, 1); >> break; >> - case KPROBE_HIT_SS: >> case KPROBE_REENTER: >> pr_warn("Failed to recover from reentered kprobes.\n"); >> dump_kprobe(p); >> -- >> 2.43.0 >> > > > -- > Masami Hiramatsu (Google) <[email protected]>
