* Mike Rapoport <rppt@xxxxxxxxxx> wrote:
> On Fri, Apr 18, 2025 at 08:33:02AM +0200, Ingo Molnar wrote:
> >
> > * Nathan Chancellor <nathan@xxxxxxxxxx> wrote:
> >
> > > Hi Mike,
> > >
> > > On Sun, Apr 13, 2025 at 11:08:58AM +0300, Mike Rapoport wrote:
> > > ...
> > > > arch/x86/kernel/e820.c | 8 ++++++++
> > > > 1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
> > > > index 57120f0749cc..5f673bd6c7d7 100644
> > > > --- a/arch/x86/kernel/e820.c
> > > > +++ b/arch/x86/kernel/e820.c
> > > > @@ -1300,6 +1300,14 @@ void __init e820__memblock_setup(void)
> > > > memblock_add(entry->addr, entry->size);
> > > > }
> > > >
> > > > + /*
> > > > + * 32-bit systems are limited to 4BG of memory even with HIGHMEM and
> > > > + * to even less without it.
> > > > + * Discard memory after max_pfn - the actual limit detected at runtime.
> > > > + */
> > > > + if (IS_ENABLED(CONFIG_X86_32))
> > > > + memblock_remove(PFN_PHYS(max_pfn), -1);
> > > > +
> > > > /* Throw away partial pages: */
> > > > memblock_trim_memory(PAGE_SIZE);
> > >
> > > Our CI noticed a boot failure after this change as commit 1e07b9fad022
> > > ("x86/e820: Discard high memory that can't be addressed by 32-bit
> > > systems") in -tip when booting i386_defconfig with a simple buildroot
> > > initrd.
> >
> > I've zapped this commit from tip:x86/urgent for the time being:
> >
> > 1e07b9fad022 ("x86/e820: Discard high memory that can't be addressed by 32-bit systems")
> >
> > until these bugs are better understood.
>
> With X86_PAE disabled phys_addr_t is 32 bit, PFN_PHYS(MAX_NONPAE_PFN)
> overflows and we get memblock_remove(0, -1) :(
>
> Using max_pfn instead of MAX_NONPAE_PFN would work because there's a hole
> under 4G and max_pfn should never overflow.
So why don't we use max_pfn like your -v1 fix did IIRC?
Ingo
