On Wed, 8 Jul 2026 07:12:39 +0000 Hongyan Xia <[email protected]> wrote:
> 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? Ah, it was more generic perf NMI case, not only preempt_enable/disable(). But anyway, the result is same. > > 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) <[email protected]>
