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.