From: Hongyan Xia <hongyan.xia@transsion.com>
To: Will Deacon <will@kernel.org>, Masami Hiramatsu <mhiramat@kernel.org>
Cc: Jiazi Li <jiazi.li@transsion.com>, Pu Hu <hupu@transsion.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [RFC PATCH 0/9] arm64: Make the kprobes debug exception path noinstr
Date: Mon, 27 Jul 2026 12:23:17 +0000 [thread overview]
Message-ID: <cover.1785153469.git.hongyan.xia@transsion.com> (raw)
From: Hongyan Xia <hongyan.xia@transsion.com>
Commit 879a6754d3d1 ("arm64: kprobes: Only handle faults originating
from XOL slot") and 23f851ac0078 ("arm64: kprobes: Allow reentering
kprobes while single-stepping") band-aided two corner cases in the arm64
kprobe path: Unrelated page faults inside Kprobe and nested Kprobe SS
handling. Although the two patches were taken, Will asked whether we
should keep patching things like this each time we find a corner case,
and whether making Kprobe noinstr is the correct answer [1].
This series attempts to do exactly that: Making the Kprobe path noinstr.
The kprobe handlers become noinstr end to end, and everything that is
inherently instrumentable is confined to instrumentation_begin/end()
windows, similar to the x86 side. After this series, the two
corner-cases mentioned above are also gone, hence the revert in 7/9 and
8/9. Some of the instrumentation_begin/end() sections are suggested by
AI, so they may need careful review.
Note that arm64 has no objtool to validate noinstr, so I wrote a small
script finding bl/blr and validated that their calls are confined within
noinstr. This is exactly what found the Clang outline compile problem
that motivated patch 9/9.
One question is whether other BRK paths get the same treatment.
Currently they stay instrumentable inside a big window.
[1] https://lore.kernel.org/all/alpuL10h7-OK2hFb@willie-the-truck/
Hongyan Xia (9):
arm64/entry: Bound certain debug exception paths in instrumentation
windows
arm64/entry: Make debug_exception_enter/exit() noinstr
arm64/debug-monitors: Make do_el1_brk64()/do_el1_softstep() noinstr
arm64/kprobes: Make the single-step machinery noinstr
arm64/kprobes: Invoke pre/post handlers inside instrumentation
arm64/kprobes: Make kprobe_fault_handler() noinstr
arm64/kprobes: Drop the KPROBE_HIT_SS reentry special case
arm64/kprobes: Drop the XOL single-step fault PC check
arm64/debug: Mark debug exception helpers __always_inline
arch/arm64/include/asm/esr.h | 2 +-
arch/arm64/include/asm/kprobes.h | 15 +----
arch/arm64/include/asm/percpu.h | 2 +-
arch/arm64/include/asm/preempt.h | 4 +-
arch/arm64/include/asm/ptrace.h | 4 +-
arch/arm64/kernel/debug-monitors.c | 76 ++++++++++++-----------
arch/arm64/kernel/entry-common.c | 43 +++++++++----
arch/arm64/kernel/probes/kprobes.c | 96 ++++++++++++++----------------
include/linux/kprobes.h | 8 +--
9 files changed, 131 insertions(+), 119 deletions(-)
--
2.47.3
next reply other threads:[~2026-07-27 12:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 12:23 Hongyan Xia [this message]
2026-07-27 12:25 ` [RFC PATCH 1/9] arm64/entry: Bound certain debug exception paths in instrumentation windows Hongyan Xia
2026-07-27 12:25 ` [RFC PATCH 2/9] arm64/entry: Make debug_exception_enter/exit() noinstr Hongyan Xia
2026-07-27 12:25 ` [RFC PATCH 3/9] arm64/debug-monitors: Make do_el1_brk64()/do_el1_softstep() noinstr Hongyan Xia
2026-07-27 12:25 ` [RFC PATCH 4/9] arm64/kprobes: Make the single-step machinery noinstr Hongyan Xia
2026-07-27 12:25 ` [RFC PATCH 5/9] arm64/kprobes: Invoke pre/post handlers inside instrumentation Hongyan Xia
2026-07-27 12:25 ` [RFC PATCH 6/9] arm64/kprobes: Make kprobe_fault_handler() noinstr Hongyan Xia
2026-07-27 12:25 ` [RFC PATCH 7/9] arm64/kprobes: Drop the KPROBE_HIT_SS reentry special case Hongyan Xia
2026-07-27 12:25 ` [RFC PATCH 8/9] arm64/kprobes: Drop the XOL single-step fault PC check Hongyan Xia
2026-07-27 12:25 ` [RFC PATCH 9/9] arm64/debug: Mark debug exception helpers __always_inline Hongyan Xia
2026-07-27 19:22 ` Nick Desaulniers
2026-07-27 21:49 ` Will Deacon
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=cover.1785153469.git.hongyan.xia@transsion.com \
--to=hongyan.xia@transsion.com \
--cc=hupu@transsion.com \
--cc=jiazi.li@transsion.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=will@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.