(drop all the non-x86 and non-mm recipients)
Hi,
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...
Acked-by: Dave Hansen dave.hansen@linux.intel.com # x86 Signed-off-by: Mike Rapoport (Microsoft) rppt@kernel.org
arch/alpha/mm/init.c | 1 - arch/arc/mm/init.c | 2 -- arch/arm64/mm/init.c | 2 -- arch/csky/mm/init.c | 1 - arch/hexagon/mm/init.c | 6 ------ arch/loongarch/kernel/numa.c | 1 - arch/loongarch/mm/init.c | 2 -- arch/microblaze/mm/init.c | 2 -- arch/mips/mm/init.c | 2 -- arch/nios2/mm/init.c | 6 ------ arch/openrisc/mm/init.c | 2 -- arch/parisc/mm/init.c | 1 - arch/riscv/mm/init.c | 1 - arch/s390/mm/init.c | 2 -- arch/sh/mm/init.c | 7 ------- arch/sparc/mm/init_32.c | 1 - arch/sparc/mm/init_64.c | 2 -- arch/um/kernel/um_arch.c | 1 - arch/x86/kernel/setup.c | 2 -- arch/x86/mm/init_32.c | 3 --- arch/x86/mm/numa_32.c | 3 --- arch/xtensa/mm/init.c | 2 -- mm/memory.c | 8 -------- mm/mm_init.c | 30 ++++++++++++++++++++++++++++++ mm/nommu.c | 2 -- 25 files changed, 30 insertions(+), 62 deletions(-)
<snip>
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.
memblock_set_node(0, PHYS_ADDR_MAX, &memblock.memory, 0);
On Wed, Apr 02, 2025 at 02:19:01PM +0200, Thomas Weißschuh wrote:
(drop all the non-x86 and non-mm recipients)
Hi,
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").
memblock_set_node(0, PHYS_ADDR_MAX, &memblock.memory, 0);
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.
memblock_set_node(0, PHYS_ADDR_MAX, &memblock.memory, 0);
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
On Wed, 2 Apr 2025 at 22:01, Thomas Weißschuh thomas.weissschuh@linutronix.de wrote:
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:
I have applied this patch,
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?
I have applied the proposed fix patch and tested. The boot test and LTP smoke test pass.
Links: - https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/naresh/tests/2vBZguDGi...
Thomas
On Wed, Apr 02, 2025 at 06:31:02PM +0200, Thomas Weißschuh wrote:
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);
This will leave HIGHMEM completely unusable. The proper fix is
diff --git a/mm/memblock.c b/mm/memblock.c index 64ae678cd1d1..d7ff8dfe5f88 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -2166,6 +2166,9 @@ static unsigned long __init __free_memory_core(phys_addr_t start, unsigned long start_pfn = PFN_UP(start); unsigned long end_pfn = PFN_DOWN(end);
+ if (!IS_ENABLED(CONFIG_HIGHMEM) && end_pfn > max_low_pfn) + end_pfn = max_low_pfn; + if (start_pfn >= end_pfn) return 0;
I've sent it along with the fix for x86 [1] (commit 7790c9c9265e ("memblock: don't release high memory to page allocator when HIGHMEM is off") in mm-unstable), but for some reason it didn't make it to the Linus tree :/
@Andrew, are you going to send it to Linus or you prefer if I take it via memblock tree?
[1] https://lore.kernel.org/all/20250325114928.1791109-3-rppt@kernel.org/
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
On Wed, 2 Apr 2025 23:18:55 +0300 Mike Rapoport rppt@kernel.org wrote:
The proper fix is
diff --git a/mm/memblock.c b/mm/memblock.c index 64ae678cd1d1..d7ff8dfe5f88 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -2166,6 +2166,9 @@ static unsigned long __init __free_memory_core(phys_addr_t start, unsigned long start_pfn = PFN_UP(start); unsigned long end_pfn = PFN_DOWN(end);
- if (!IS_ENABLED(CONFIG_HIGHMEM) && end_pfn > max_low_pfn)
end_pfn = max_low_pfn;- if (start_pfn >= end_pfn) return 0;
I've sent it along with the fix for x86 [1] (commit 7790c9c9265e ("memblock: don't release high memory to page allocator when HIGHMEM is off") in mm-unstable), but for some reason it didn't make it to the Linus tree :/
@Andrew, are you going to send it to Linus or you prefer if I take it via memblock tree?
[1] https://lore.kernel.org/all/20250325114928.1791109-3-rppt@kernel.org/
That fix is now in mm-stable for a second round of merge window material. I'll send that off to Linus later today.
-
Andrew Morton -
Mike Rapoport -
Naresh Kamboju -
Thomas Weißschuh