linux-kernel - Re: [PATCH v2 10/13] arch, mm: set high_memory in free_area

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250402145330-3ff21a6b-fb03-4bc8-8178-51a535582c6f@linutronix.de>
Date: Wed, 2 Apr 2025 15:07:50 +0200
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Mike Rapoport <rppt@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, Andy Lutomirski <luto@...nel.org>, 
	Ard Biesheuvel <ardb@...nel.org>, Arnd Bergmann <arnd@...db.de>, Borislav Petkov <bp@...en8.de>, 
	"David S. Miller" <davem@...emloft.net>, Geert Uytterhoeven <geert@...ux-m68k.org>, 
	Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>, 
	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org, 
	linux-mm@...ck.org, x86@...nel.org, Naresh Kamboju <naresh.kamboju@...aro.org>, 
	lkft-triage@...ts.linaro.org, Linux Regressions <regressions@...ts.linux.dev>
Subject: Re: [PATCH v2 10/13] arch, mm: set high_memory in free_area_init()

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@...nel.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);