On 5/28/26 4:23 PM, Wang Han wrote:
KASAN records stack traces for every alloc/free, which means it walks
the unwinder very frequently. Instrumenting the stack trace collection
code itself adds substantial overhead and makes the traces themselves
noisier.
Mark stacktrace.o as not KASAN-instrumented, matching the arm, arm64
and x86 treatment of their stack unwinding code. This is a prerequisite
preference for the upcoming reliable unwinder, but the change is valid
on its own.
Signed-off-by: Wang Han <[email protected]>
---
arch/riscv/kernel/Makefile | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index cabb99cadfb6..1cb6c9ab2981 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -44,6 +44,11 @@ CFLAGS_REMOVE_return_address.o = $(CC_FLAGS_FTRACE)
CFLAGS_REMOVE_sbi_ecall.o = $(CC_FLAGS_FTRACE)
endif
+# When KASAN is enabled, a stack trace is recorded for every alloc/free, which
+# can significantly impact performance. Avoid instrumenting the stack trace
+# collection code to minimize this impact.
+KASAN_SANITIZE_stacktrace.o := n
+
I checked the three referenced arches:
- arm (arch/arm/kernel/Makefile): KASAN only
- arm64 (arch/arm64/kernel/Makefile): KASAN only
- x86 (arch/x86/kernel/Makefile): KASAN *and* KCOV
(KCOV_INSTRUMENT_stacktrace.o := n, plus dumpstack and
the unwind_*.o TUs)
So as written, this patch matches arm/arm64 but NOT x86. KCOV
instruments every basic-block edge; the unwinder is a hot path
(doubly so under KASAN, where it runs on every alloc/free), so the
same rationale that justifies disabling KASAN applies to KCOV. I'd
suggest making the claim true by adding:
KCOV_INSTRUMENT_stacktrace.o := n
(RISC-V keeps its entire unwinder in stacktrace.o, so unlike x86
there's no dumpstack/unwind_*.o to also annotate — the single TU
covers the equivalent scope.)
Alternatively, if you'd rather keep it minimal, just drop "and x86"
from the changelog so the claim matches the code.
Thanks.
Shuai
