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

[Karl Mehltretter <kmehltretter@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3082 bytes --]

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

[-- Attachment #2: arm64-kcov.config.gz --]
[-- Type: application/x-gunzip, Size: 11591 bytes --]

[-- Attachment #3: arm64-kcov-trace-irqsoff-crash.log.gz --]
[-- Type: application/x-gunzip, Size: 4458 bytes --]