diff mbox series

[v2,1/2] arm64: kasan: do not instrument stacktrace.c

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

Commit Message

andrey.konovalov@linux.dev May 23, 2022, 2:51 p.m. UTC
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.

Also replace READ_ONCE_NOCHECK() with READ_ONCE() in stacktrace.c.
As the file is now not instrumented, there is no need to use the
NOCHECK version of READ_ONCE().

Suggested-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>

---

Changes v1->v2:
- Updated the comment in Makefile as suggested by Mark.

---
 arch/arm64/kernel/Makefile     | 5 +++++
 arch/arm64/kernel/stacktrace.c | 4 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

Comments

Will Deacon June 23, 2022, 7:31 p.m. UTC | #1
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,
Mark Rutland June 26, 2022, 9:21 a.m. UTC | #2
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.
diff mbox series

Patch

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;