Re: [REGRESSION] x86_32 boot hang in 6.19-rc7 caused by b505f1944535 ("x86/kfence: avoid writing L1TF-vulnerable PTEs")

[Andrew Cooper]

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