Re: [PATCH v7 11/11] unwind: arm64: Use sframe to unwind interrupt frames
From: sashiko-bot@kernel.org
Date: 2026-09-18 23:00:55
Also in:
linux-arm-kernel, live-patching, lkml
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] arm64: noinstr violation by calling sframe_find() in stack unwinder -- commit 13ca4d55a43f451bf08442b7e6af494a6c23a78e Author: Dylan Hatch [off-list ref] unwind: arm64: Use sframe to unwind interrupt frames This patch adds kunwind_next_regs_sframe() to unwind interrupt frames using sframe info, falling back to frame-pointer unwinding on failure. It updates the exception boundary unwinding logic to recover the return address more reliably when sframe data is present.
quoted hunk ↗ jump to hunk
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c index 3ebcf8c53fb04..5aaeac9611015 100644 --- a/arch/arm64/kernel/stacktrace.c +++ b/arch/arm64/kernel/stacktrace.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -244,6 +247,162 @@ kunwind_next_frame_record(struct kunwind_state *state) return 0; } +#ifdef CONFIG_HAVE_UNWIND_KERNEL_SFRAME
[ ... ]
+/*
+ * Unwind from a pt_regs according to sframe.
+ */
+static __always_inline int
+kunwind_next_regs_sframe(struct kunwind_state *state)
+{
+ struct unwind_frame frame;
+ unsigned long cfa, fp, ra;
+ enum kunwind_source source = KUNWIND_SOURCE_FRAME;
+ struct pt_regs *regs = state->regs;
+
+ int err;
+
+ if (WARN_ON_ONCE(state->source != KUNWIND_SOURCE_REGS_PC))
+ return -EINVAL;
+ if (WARN_ON_ONCE(!state->regs))
+ return -EINVAL;
+
+ /* FP/SP alignment 8 bytes */
+ if (state->common.fp & 0x7)
+ return -EINVAL;
+
+ err = sframe_find(state->common.pc, &frame);[Severity: High] Does calling sframe_find() here violate the noinstr guarantee of the stack unwinding path? The unwind path is called via arch_stack_walk() -> kunwind_stack_walk() -> kunwind_next() -> kunwind_next_regs_sframe(). Since arch_stack_walk() is explicitly marked noinstr to guarantee safe execution in uninstrumentable contexts (like nmi), calling instrumentable or rcu-protected functions like sframe_find() and __module_text_address() could cause a recursive fault or kernel panic if tracing or kasan is active. Additionally, could accessing rcu-protected module structures without rcu watching lead to use-after-free bugs when stack unwinding is routinely triggered by tools like perf or bpf tracing?
+ if (err) + return -EINVAL; +
-- Sashiko AI review · https://sashiko.dev/#/patchset/20260918224157.1471085-1-dylanbhatch@google.com?part=11