From nobody Thu Apr 2 14:10:34 2026 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AB34033AD91 for ; Fri, 27 Mar 2026 22:36:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=96.67.55.147 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774650972; cv=none; b=HI3An40rhiRJhch3MgtT6BWLgvGRyr54CSA9NlTGokN4Bb2DTrrkP/1UbD0syWbKtt7EabY+feQcbHA1iHT5mMORUNpag2WgoIxbMoeQjsQk5POT4czrg6RWc26Vbmm4apHM1ziCF3BQ7yuogNBakjrJP95oGC+utunyCoRM88Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774650972; c=relaxed/simple; bh=qWruPd/zuIftvsAjLtjxTKZS+U8A+oycJro/aj+6KmM=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=BiCnk8FeAGbxnsJgDw1EQQZFIR1Gk2Kp1XsWf8Vc0CJcnS8J63u5xkLdDidURe3dV6BNnX75HFcBSwgsfTnwMJhIRQvprATOahmKIYx9I4I1rOm9H2SboYIz/N54uPskrH4NT2xJ6Evf6qJw0yfaPtUDGSsUfU/M0vRMtWTbVHE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com; spf=pass smtp.mailfrom=surriel.com; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b=ICADGHWX; arc=none smtp.client-ip=96.67.55.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=surriel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b="ICADGHWX" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=surriel.com ; s=mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=hOieWCFq2v4VdxzNyv43CNEGPtlIIeRBFLXaMlGUz1s=; b=ICADGHWXcdgaKQZogOA2ykgCxk nEdcPRmYX9n6QcRNzWuLRdxvzwujnl22jLqdnPrAzy3K5Q2FCgm3v9w1YmC83wgDFMkofYJFFzRbc S/dYwzFWVxKguhq5o2r+uZhuTZMNp/HaC+ZbvACQlvy1TrQxmd9eeo1eO8XxFOx+7VV4OGXSq1kLO WzJ6ckGwgOgnV5woBHQEj8VTJM4t8R/TGrlwjXiLCwyiDpQ/1PBdBivP6l1+4MA5/IiGUTUoa6cCs uk/fMwmyghPfxCMvk7etQ0fmbfVbE8RtzBlwJMICC893bpQanUOCim0LafzJEsDyrr4PqRQc1neLF VBccWzGw==; Received: from [2601:18c:8180:83cc::4801] (helo=fangorn) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1w6Fmg-00000000800-048V; Fri, 27 Mar 2026 18:36:06 -0400 Date: Fri, 27 Mar 2026 18:36:05 -0400 From: Rik van Riel To: linux-kernel@vger.kernel.org Cc: x86@kernel.org, kernel-team@meta.com, Kai Huang , David Woodhouse , Coiby Xu , Peter Zijlstra , Borislav Petkov Subject: [PATCH] disable KCOV coverage for kexec code Message-ID: <20260327183605.5f7d0efd@fangorn> X-Mailer: Claws Mail 4.3.1 (GTK 3.24.49; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 --=20 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 :=3D n KCOV_INSTRUMENT_unwind_orc.o :=3D n KCOV_INSTRUMENT_unwind_frame.o :=3D n KCOV_INSTRUMENT_unwind_guess.o :=3D n +# machine_kexec accesses per-CPU data via GS during kexec; KCOV instrument= ation +# there causes page faults =E2=86=92 exception stack overflow =E2=86=92 do= uble fault, preventing +# kdump crash kernel from booting. +KCOV_INSTRUMENT_machine_kexec_64.o :=3D n +KCOV_INSTRUMENT_machine_kexec.o :=3D n =20 CFLAGS_head32.o :=3D -fno-stack-protector CFLAGS_head64.o :=3D -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 :=3D n KCOV_INSTRUMENT_stacktrace.o :=3D n # Don't self-instrument. KCOV_INSTRUMENT_kcov.o :=3D 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 :=3D n +KCOV_INSTRUMENT_kexec.o :=3D n # If sanitizers detect any issues in kcov, it may lead to recursion # via printk, etc. KASAN_SANITIZE_kcov.o :=3D n