Message ID | c4c944a2a905e949760fbeb29258185087171708.1653317461.git.andreyknvl@google.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [v2,1/2] arm64: kasan: do not instrument stacktrace.c | expand |
On Mon, 23 May 2022 16:51:51 +0200, andrey.konovalov@linux.dev wrote: > From: Andrey Konovalov <andreyknvl@google.com> > > Disable KASAN instrumentation of arch/arm64/kernel/stacktrace.c. > > This speeds up Generic KASAN by 5-20%. > > As a side-effect, KASAN is now unable to detect bugs in the stack trace > collection code. This is taken as an acceptable downside. > > [...] Applied to arm64 (for-next/stacktrace), thanks! I had to fix conflicts in both of the patches, so please can you take a quick look at the result? [1/2] arm64: kasan: do not instrument stacktrace.c https://git.kernel.org/arm64/c/802b91118d11 [2/2] arm64: stacktrace: use non-atomic __set_bit https://git.kernel.org/arm64/c/446297b28a21 Cheers,
On Thu, Jun 23, 2022 at 08:31:32PM +0100, Will Deacon wrote: > On Mon, 23 May 2022 16:51:51 +0200, andrey.konovalov@linux.dev wrote: > > From: Andrey Konovalov <andreyknvl@google.com> > > > > Disable KASAN instrumentation of arch/arm64/kernel/stacktrace.c. > > > > This speeds up Generic KASAN by 5-20%. > > > > As a side-effect, KASAN is now unable to detect bugs in the stack trace > > collection code. This is taken as an acceptable downside. > > > > [...] > > Applied to arm64 (for-next/stacktrace), thanks! I had to fix conflicts > in both of the patches, so please can you take a quick look at the result? > > [1/2] arm64: kasan: do not instrument stacktrace.c > https://git.kernel.org/arm64/c/802b91118d11 > [2/2] arm64: stacktrace: use non-atomic __set_bit > https://git.kernel.org/arm64/c/446297b28a21 I take it that was just the s/frame/state/ conflict? FWIW, that looks good to me; thanks for sorting that out! Mark.
On Thu, Jun 23, 2022 at 9:31 PM Will Deacon <will@kernel.org> wrote: > > On Mon, 23 May 2022 16:51:51 +0200, andrey.konovalov@linux.dev wrote: > > From: Andrey Konovalov <andreyknvl@google.com> > > > > Disable KASAN instrumentation of arch/arm64/kernel/stacktrace.c. > > > > This speeds up Generic KASAN by 5-20%. > > > > As a side-effect, KASAN is now unable to detect bugs in the stack trace > > collection code. This is taken as an acceptable downside. > > > > [...] > > Applied to arm64 (for-next/stacktrace), thanks! I had to fix conflicts > in both of the patches, so please can you take a quick look at the result? > > [1/2] arm64: kasan: do not instrument stacktrace.c > https://git.kernel.org/arm64/c/802b91118d11 > [2/2] arm64: stacktrace: use non-atomic __set_bit > https://git.kernel.org/arm64/c/446297b28a21 Hi Will, The updated patches look good. Thanks!
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile index fa7981d0d917..7075a9c6a4a6 100644 --- a/arch/arm64/kernel/Makefile +++ b/arch/arm64/kernel/Makefile @@ -14,6 +14,11 @@ CFLAGS_REMOVE_return_address.o = $(CC_FLAGS_FTRACE) CFLAGS_REMOVE_syscall.o = -fstack-protector -fstack-protector-strong CFLAGS_syscall.o += -fno-stack-protector +# 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 + # It's not safe to invoke KCOV when portions of the kernel environment aren't # available or are out-of-sync with HW state. Since `noinstr` doesn't always # inhibit KCOV instrumentation, disable it for the entire compilation unit. diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c index e4103e085681..33e96ae4b15f 100644 --- a/arch/arm64/kernel/stacktrace.c +++ b/arch/arm64/kernel/stacktrace.c @@ -110,8 +110,8 @@ static int notrace unwind_frame(struct task_struct *tsk, * Record this frame record's values and location. The prev_fp and * prev_type are only meaningful to the next unwind_frame() invocation. */ - frame->fp = READ_ONCE_NOCHECK(*(unsigned long *)(fp)); - frame->pc = READ_ONCE_NOCHECK(*(unsigned long *)(fp + 8)); + frame->fp = READ_ONCE(*(unsigned long *)(fp)); + frame->pc = READ_ONCE(*(unsigned long *)(fp + 8)); frame->prev_fp = fp; frame->prev_type = info.type;