Thread (3 messages) flat view 3 messages, 2 authors, 2026-05-26

Re: [PATCH] tracing: Disable KCOV instrumentation for trace_irqsoff.o

From: Karl Mehltretter <hidden>
Date: 2026-05-26 10:22:57
Also in: lkml
Subsystem: arm64 port (aarch64 architecture), the rest · Maintainers: Catalin Marinas, Will Deacon, Linus Torvalds

On Tue, May 26, 2026 at 03:07:58PM +0100, Masami Hiramatsu wrote:
Thanks for reporting. This looks good to me for a mitigation.
BTW, I could not reproduce the bug with above configs.
Is this only for arm32?
I was able to reproduce this on arm64 QEMU virt with the attached
config and log.

Test base:
  4cbfe4502e3d ("Merge tag 'v7.1-rc5-ksmbd-server-fixes' ...")

QEMU command:
  qemu-system-aarch64 \
    -machine virt,gic-version=2 -cpu cortex-a57 -m 512M -smp 1 \
    -kernel arch/arm64/boot/Image \
    -append "console=ttyAMA0,115200 earlycon=pl011,0x9000000 rdinit=/init panic_on_warn=0 oops=panic loglevel=8 printk.time=1" \
    -nographic -no-reboot

Relevant config options:
  CONFIG_TRACE_IRQFLAGS=y
  CONFIG_IRQSOFF_TRACER=y
  CONFIG_KCOV=y
  CONFIG_KCOV_INSTRUMENT_ALL=y
  CONFIG_KCOV_SELFTEST=y

The raw arm64 crash first runs into other KCOV-instrumented early
IRQ/stack helpers. To isolate the trace_irqsoff.o part, I used the
following additional changes. This is not intended for merge:
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 74b76bb70452..d69eb3fd0577 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -24,6 +24,9 @@ KASAN_SANITIZE_stacktrace.o := n
 # inhibit KCOV instrumentation, disable it for the entire compilation unit.
 KCOV_INSTRUMENT_entry-common.o := n
 KCOV_INSTRUMENT_idle.o := n
+KCOV_INSTRUMENT_irq.o := n
+KCOV_INSTRUMENT_return_address.o := n
+KCOV_INSTRUMENT_stacktrace.o := n
 
 # Object file lists.
 obj-y			:= debug-monitors.o entry.o irq.o fpsimd.o		\
diff --git a/kernel/time/Makefile b/kernel/time/Makefile
index eaf290c972f9..2641a44f6339 100644
--- a/kernel/time/Makefile
+++ b/kernel/time/Makefile
@@ -21,6 +21,7 @@ ifeq ($(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST),y)
  obj-$(CONFIG_TICK_ONESHOT)			+= tick-broadcast-hrtimer.o
 endif
 obj-$(CONFIG_GENERIC_SCHED_CLOCK)		+= sched_clock.o
+KCOV_INSTRUMENT_sched_clock.o := n
 obj-$(CONFIG_TICK_ONESHOT)			+= tick-oneshot.o tick-sched.o
 obj-$(CONFIG_LEGACY_TIMER_TICK)			+= tick-legacy.o
 ifeq ($(CONFIG_SMP),y)
With these changes, but with trace_irqsoff.o still instrumented,
the kernel still crashes during the KCOV selftest:

  kcov: running self test
  pc : __sanitizer_cov_trace_pc+0x64/0x84
  Kernel panic - not syncing: kernel stack overflow
  ...
  tracer_hardirqs_off+0x1c/0x78
  trace_hardirqs_off.part.0+0x70/0x1a0
  trace_hardirqs_off_finish+0x60/0x6c
  arm64_enter_from_kernel_mode.isra.0+0x18/0x38
  el1_interrupt+0x24/0x58
  el1h_64_irq+0x6c/0x70
  kcov_init+0xc8/0x118

Then adding the line from my original ARMv5
mitigation makes the arm64 kernel boot through the KCOV selftest:

  KCOV_INSTRUMENT_trace_irqsoff.o := n

The boot log then shows:

  kcov: running self test
  kcov: done running self test
  tiny-init: reached userspace

So arm64 also confirms that trace_irqsoff.o is reachable from this early
IRQ entry path while KCOV selftest mode is active.

Arm64 appears to have additional KCOV/early-entry paths with this config,
which probably need to be investigated independently.

Regards,
Karl

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help