On Wed, 8 Jul 2026 07:12:39 +0000
Hongyan Xia [off-list ref] wrote:

On 7/8/2026 8:54 AM, Masami Hiramatsu wrote:

quoted

On Mon, 6 Jul 2026 08:36:49 +0000
Pu Hu [off-list ref] 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.

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?

Ah, it was more generic perf NMI case, not only preempt_enable/disable().
But anyway, the result is same.

quoted

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.

OK, thanks!


-- 
Masami Hiramatsu (Google) [off-list ref]