[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <062eb8bd-3d98-4a0a-baf4-8f59b7643041@citrix.com>
Date: Mon, 26 Jan 2026 19:39:51 +0000
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Ryusuke Konishi <konishi.ryusuke@...il.com>
Cc: Andrew Cooper <andrew.cooper3@...rix.com>,
Andrew Morton <akpm@...ux-foundation.org>, Marco Elver <elver@...gle.com>,
LKML <linux-kernel@...r.kernel.org>, Alexander Potapenko
<glider@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
X86 ML <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
Jann Horn <jannh@...gle.com>, kasan-dev@...glegroups.com
Subject: Re: [REGRESSION] x86_32 boot hang in 6.19-rc7 caused by b505f1944535
("x86/kfence: avoid writing L1TF-vulnerable PTEs")
On 26/01/2026 7:07 pm, Ryusuke Konishi wrote:
> Hi All,
>
> I am reporting a boot regression in v6.19-rc7 on an x86_32
> environment. The kernel hangs immediately after "Booting the kernel"
> and does not produce any early console output.
>
> A git bisect identified the following commit as the first bad commit:
> b505f1944535 ("x86/kfence: avoid writing L1TF-vulnerable PTEs")
>
> Environment and Config:
> - Guest Arch: x86_32 (one of my test VMs)
> - Memory Config: # CONFIG_X86_PAE is not set
> - KFENCE Config: CONFIG_KFENCE=y
> - Host/Hypervisor: x86_64 host running KVM
>
> The system fails to boot at a very early stage. I have confirmed that
> reverting commit b505f1944535 on top of v6.19-rc7 completely resolves
> the issue, and the kernel boots normally.
>
> Could you please verify if this change is compatible with x86_32
> (non-PAE) configurations?
> I am happy to provide my full .config or test any potential fixes.
Hmm. To start with, does this fix the crash?
diff --git a/arch/x86/include/asm/kfence.h b/arch/x86/include/asm/kfence.h
index acf9ffa1a171..2fe454722e54 100644
--- a/arch/x86/include/asm/kfence.h
+++ b/arch/x86/include/asm/kfence.h
@@ -67,8 +67,6 @@ static inline bool kfence_protect_page(unsigned long addr, bool protect)
* If the page was protected (non-present) and we're making it
* present, there is no need to flush the TLB at all.
*/
- if (!protect)
- return true;
/*
* We need to avoid IPIs, as we may get KFENCE allocations or faults
Re-reading, I can't spot anything obvious.
Architecturally, x86 explicitly does not need a TLB flush when turning a
non-present mapping present, and it's strictly 4k leaf mappings we're
handling here.
I wonder if something else is missing a flush, and was being covered by
this.
~Andrew
Powered by blists - more mailing lists