[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKFNMok_hSMoJJcFUOSLPNcyHUD+um99Botn3B9YbBYYZeKvRQ@mail.gmail.com>
Date: Tue, 27 Jan 2026 04:52:30 +0900
From: Ryusuke Konishi <konishi.ryusuke@...il.com>
To: Andrew Cooper <andrew.cooper3@...rix.com>
Cc: 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 Tue, Jan 27, 2026 at 4:39 AM Andrew Cooper wrote:
>
> 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
I tested this change, but unfortunately the boot hang still occurs.
Regards,
Ryusuke Konishi
Powered by blists - more mailing lists