On Wed, Apr 02, 2025 at 03:07:51PM +0200, Thomas Weißschuh wrote:
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+G9fYtdXHVuirs3v6at3UoKNH5keuq0tpcvpz0tJFT4to...
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.
The issue is fixed with the following diff:
diff --git a/mm/memblock.c b/mm/memblock.c index 284154445409..8cd95f60015d 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -2165,7 +2165,8 @@ static unsigned long __init __free_memory_core(phys_addr_t start, phys_addr_t end) { unsigned long start_pfn = PFN_UP(start); - unsigned long end_pfn = PFN_DOWN(end); + unsigned long end_pfn = min_t(unsigned long, + PFN_DOWN(end), max_low_pfn);
if (start_pfn >= end_pfn) return 0;
Background:
This reverts part of commit 6faea3422e3b ("arch, mm: streamline HIGHMEM freeing") which is the direct child of the partially reverted commit e120d1bc12da ("arch, mm: set high_memory in free_area_init()"). The assumptions the former commit became invalid with the partial revert the latter.
This bug only triggers when CONFIG_HIGHMEM=n. When mm was branched from mainline the i386 configuration generated by kunit ended up with CONFIG_HIGHMEM=y. With some recent changes in mainline the kunit configuration switched to CONFIG_HIGHMEM=n, triggering this specific reproducer only when mm got merged into mainline again.
New kunit reproducer: ./tools/testing/kunit/kunit.py run --arch i386 example --timeout 10 --kconfig_add CONFIG_HIGHMEM=n
Does this sound reasonable? If so I'll send a patch tomorrow.
@Naresh, could you test this, too?
Thomas