Re: [PATCH v2 10/13] arch, mm: set high_memory in free_area_init()

["Thomas Weißschuh" <thomas.weissschuh@linutronix.de>]

On Wed, Apr 02, 2025 at 03:46:37PM +0300, Mike Rapoport wrote:
> On Wed, Apr 02, 2025 at 02:19:01PM +0200, Thomas Weißschuh wrote:
> > (drop all the non-x86 and non-mm recipients)
> > 
> > On Thu, Mar 13, 2025 at 03:50:00PM +0200, Mike Rapoport wrote:
> > > From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
> > > 
> > > high_memory defines upper bound on the directly mapped memory.
> > > This bound is defined by the beginning of ZONE_HIGHMEM when a system has
> > > high memory and by the end of memory otherwise.
> > > 
> > > All this is known to generic memory management initialization code that
> > > can set high_memory while initializing core mm structures.
> > > 
> > > Add a generic calculation of high_memory to free_area_init() and remove
> > > per-architecture calculation except for the architectures that set and
> > > use high_memory earlier than that.
> > 
> > This change (in mainline as commit e120d1bc12da ("arch, mm: set high_memory in free_area_init()")
> > breaks booting i386 on QEMU for me (and others [0]).
> > The boot just hangs without output.
> > 
> > It's easily reproducible with kunit:
> > ./tools/testing/kunit/kunit.py run --arch i386
> > 
> > See below for the specific problematic hunk.
> > 
> > [0] https://lore.kernel.org/lkml/CA+G9fYtdXHVuirs3v6at3UoKNH5keuq0tpcvpz0tJFT4toLG4g@mail.gmail.com/
> > 
> > 
> > > diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
> > > index 6d2f8cb9451e..801b659ead0c 100644
> > > --- a/arch/x86/mm/init_32.c
> > > +++ b/arch/x86/mm/init_32.c
> > > @@ -643,9 +643,6 @@ void __init initmem_init(void)
> > >  		highstart_pfn = max_low_pfn;
> > >  	printk(KERN_NOTICE "%ldMB HIGHMEM available.\n",
> > >  		pages_to_mb(highend_pfn - highstart_pfn));
> > > -	high_memory = (void *) __va(highstart_pfn * PAGE_SIZE - 1) + 1;
> > > -#else
> > > -	high_memory = (void *) __va(max_low_pfn * PAGE_SIZE - 1) + 1;
> > >  #endif
> > 
> > Reverting this hunk fixes the issue for me.
>  
> This is already done by d893aca973c3 ("x86/mm: restore early initialization
> of high_memory for 32-bits").

Thanks. Of course I only noticed this shortly after sending my mail.
But this usecase is indeed broken on mainline.
Some further bisecting lead to the mm merge commit being broken, while both its
parents work. That lead the bisection astray.
eb0ece16027f ("Merge tag 'mm-stable-2025-03-30-16-52' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm")

As unlikely as it sounds, it's reproducible. I'll investigate a bit.

> > >  	memblock_set_node(0, PHYS_ADDR_MAX, &memblock.memory, 0);