From: Pu Hu <hupu@transsion.com>
To: "catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"will@kernel.org" <will@kernel.org>,
"naveen@kernel.org" <naveen@kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"mhiramat@kernel.org" <mhiramat@kernel.org>,
"yang@os.amperecomputing.com" <yang@os.amperecomputing.com>,
Hongyan Xia <hongyan.xia@transsion.com>,
Jiazi Li <jiazi.li@transsion.com>,
"ada.coupriediaz@arm.com" <ada.coupriediaz@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-trace-kernel@vger.kernel.org"
<linux-trace-kernel@vger.kernel.org>
Cc: Pu Hu <hupu@transsion.com>
Subject: [RFC 1/2] arm64: kprobes: Do not handle non-XOL faults as kprobe faults
Date: Wed, 1 Jul 2026 12:14:57 +0000 [thread overview]
Message-ID: <20260701121448.3926-2-hupu@transsion.com> (raw)
In-Reply-To: <20260701121448.3926-1-hupu@transsion.com>
From: hupu <hupu@transsion.com>
kprobe_fault_handler() handles faults taken while kprobes is in
KPROBE_HIT_SS or KPROBE_REENTER state as faults caused by the
single-stepped instruction.
That assumption is not always true. While a kprobe is preparing or
executing the out-of-line single-step instruction, other code may run
in that window. For example, perf or trace code can be invoked from the
debug exception path and may take a fault of its own. In that case the
fault did not happen on the kprobe XOL instruction, but the kprobe fault
handler may still try to recover it as a kprobe single-step fault.
This can corrupt the exception recovery flow and leave the real fault to
be handled with a wrong PC. A typical reproducer is running simpleperf
with preemptirq tracepoints and dwarf callchains while a kprobe is
installed on a frequently executed kernel function.
Fix this by handling faults in KPROBE_HIT_SS/KPROBE_REENTER only when
the faulting PC points at the current kprobe's XOL instruction. Faults
from any other PC are left to the normal fault handling path.
This follows the same idea as the x86 fix in commit 6381c24cd6d5
("kprobes/x86: Fix page-fault handling logic").
Signed-off-by: hupu <hupu@transsion.com>
Signed-off-by: Hongyan Xia <hongyan.xia@transsion.com>
---
arch/arm64/kernel/probes/kprobes.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 43a0361a8bf0..e4d2852ce2fb 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -285,6 +285,20 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
switch (kcb->kprobe_status) {
case KPROBE_HIT_SS:
case KPROBE_REENTER:
+ /*
+ * A fault taken while a kprobe is single-stepping is not
+ * necessarily caused by the instruction in the XOL slot. For
+ * example, tracing or perf code running in this window may take
+ * an unrelated fault.
+ *
+ * Handle the fault here only when the faulting PC is the XOL
+ * instruction of the current kprobe. Otherwise let the normal
+ * fault handling path deal with it.
+ */
+ if (cur->ainsn.xol_insn &&
+ instruction_pointer(regs) != (unsigned long)cur->ainsn.xol_insn)
+ break;
+
/*
* We are here because the instruction being single
* stepped caused a page fault. We reset the current
--
2.43.0
next prev parent reply other threads:[~2026-07-01 12:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 12:14 [RFC 0/2] arm64: kprobes: Fix single-step fault and reentry handling Pu Hu
2026-07-01 12:14 ` Pu Hu [this message]
2026-07-01 12:15 ` [RFC 2/2] arm64: kprobes: Allow reentering kprobes while single-stepping Pu Hu
2026-07-01 12:30 ` [RFC 0/2] arm64: kprobes: Fix single-step fault and reentry handling Pu Hu
2026-07-01 13:43 ` Masami Hiramatsu
2026-07-01 13:56 ` Pu Hu
2026-07-02 10:07 ` Pu Hu
2026-07-02 10:09 ` Pu Hu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260701121448.3926-2-hupu@transsion.com \
--to=hupu@transsion.com \
--cc=ada.coupriediaz@arm.com \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=hongyan.xia@transsion.com \
--cc=jiazi.li@transsion.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=naveen@kernel.org \
--cc=will@kernel.org \
--cc=yang@os.amperecomputing.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox