All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@surriel.com>
To: linux-kernel@vger.kernel.org
Cc: x86@kernel.org, kernel-team@meta.com,
	Kai Huang <kai.huang@intel.com>,
	David Woodhouse <dwmw@amazon.co.uk>, Coiby Xu <coxu@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Borislav Petkov <bp@alien8.de>
Subject: [PATCH] disable KCOV coverage for kexec code
Date: Fri, 27 Mar 2026 18:36:05 -0400	[thread overview]
Message-ID: <20260327183605.5f7d0efd@fangorn> (raw)

Trying to have code coverage for the kexec code results in
kexec-on-panic not working in a syzkaller setup.

Excluding the kexec code from code coverage makes it work again.

I cannot take credit for figuring this one out, this was all
done by Claude driving a syzkaller setup, and examining the
guest vcpu register dumps to figure out why kdump in the guest
wasn't working. Now Claude has access to vmcores.

Signed-off-by: Rik van Riel <riel@surriel.com>

-- 

diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index e9aeeeafad173..eeea5167f4ff5 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -43,6 +43,11 @@ KCOV_INSTRUMENT_dumpstack_$(BITS).o			:= n
 KCOV_INSTRUMENT_unwind_orc.o				:= n
 KCOV_INSTRUMENT_unwind_frame.o				:= n
 KCOV_INSTRUMENT_unwind_guess.o				:= n
+# machine_kexec accesses per-CPU data via GS during kexec; KCOV instrumentation
+# there causes page faults → exception stack overflow → double fault, preventing
+# kdump crash kernel from booting.
+KCOV_INSTRUMENT_machine_kexec_64.o			:= n
+KCOV_INSTRUMENT_machine_kexec.o			:= n
 
 CFLAGS_head32.o := -fno-stack-protector
 CFLAGS_head64.o := -fno-stack-protector
diff --git a/kernel/Makefile b/kernel/Makefile
index 6785982013dce..a1571d32cbb9d 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -37,6 +37,10 @@ KCOV_INSTRUMENT_extable.o := n
 KCOV_INSTRUMENT_stacktrace.o := n
 # Don't self-instrument.
 KCOV_INSTRUMENT_kcov.o := n
+# kexec_core.c contains __crash_kexec / machine_kexec paths that run with
+# degraded CPU state; KCOV instrumentation there causes per-CPU GS faults.
+KCOV_INSTRUMENT_kexec_core.o := n
+KCOV_INSTRUMENT_kexec.o := n
 # If sanitizers detect any issues in kcov, it may lead to recursion
 # via printk, etc.
 KASAN_SANITIZE_kcov.o := n


                 reply	other threads:[~2026-03-27 22:36 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260327183605.5f7d0efd@fangorn \
    --to=riel@surriel.com \
    --cc=bp@alien8.de \
    --cc=coxu@redhat.com \
    --cc=dwmw@amazon.co.uk \
    --cc=kai.huang@intel.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.