From: Mike Rapoport <rppt@kernel.org>
To: Klara Modin <klarasmodin@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Alex Shi <alexs@kernel.org>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Andreas Larsson <andreas@gaisler.com>,
Borislav Petkov <bp@alien8.de>, Brian Cain <bcain@kernel.org>,
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
"David S. Miller" <davem@davemloft.net>,
Dave Hansen <dave.hansen@linux.intel.com>,
David Hildenbrand <david@kernel.org>,
Dinh Nguyen <dinguyen@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Guo Ren <guoren@kernel.org>, Heiko Carstens <hca@linux.ibm.com>,
Helge Deller <deller@gmx.de>, Huacai Chen <chenhuacai@kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Johannes Berg <johannes@sipsolutions.net>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Jonathan Corbet <corbet@lwn.net>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Magnus Lindholm <linmag7@gmail.com>,
Matt Turner <mattst88@gmail.com>,
Max Filippov <jcmvbkbc@gmail.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Michal Hocko <mhocko@suse.com>, Michal Simek <monstr@monstr.eu>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
Palmer Dabbelt <palmer@dabbelt.com>,
Pratyush Yadav <pratyush@kernel.org>,
Richard Weinberger <richard@nod.at>,
Russell King <linux@armlinux.org.uk>,
Stafford Horne <shorne@gmail.com>,
Suren Baghdasaryan <surenb@google.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Thomas Gleixner <tglx@linutronix.de>,
Vasily Gorbik <gor@linux.ibm.com>,
Vineet Gupta <vgupta@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>, Will Deacon <will@kernel.org>,
x86@kernel.org, linux-alpha@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org,
linux-cxl@vger.kernel.org, linux-doc@vger.kernel.org,
linux-hexagon@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
linux-mm@kvack.org, linux-openrisc@vger.kernel.org,
linux-parisc@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
linux-snps-arc@lists.infradead.org, linux-um@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev,
sparclinux@vger.kernel.org
Subject: Re: [PATCH v2 22/28] arch, mm: consolidate initialization of nodes, zones and memory map
Date: Sat, 3 Jan 2026 20:54:23 +0200 [thread overview]
Message-ID: <aVll339wim7dCIaQ@kernel.org> (raw)
In-Reply-To: <aVhN2NgQEKe0yzva@soda.int.kasm.eu>
Hi,
On Sat, Jan 03, 2026 at 12:33:29AM +0100, Klara Modin wrote:
> On 2026-01-02 08:59:58 +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
> >
> > To initialize node, zone and memory map data structures every architecture
> > calls free_area_init() during setup_arch() and passes it an array of zone
> > limits.
> >
> > Beside code duplication it creates "interesting" ordering cases between
> > allocation and initialization of hugetlb and the memory map. Some
> > architectures allocate hugetlb pages very early in setup_arch() in certain
> > cases, some only create hugetlb CMA areas in setup_arch() and sometimes
> > hugetlb allocations happen mm_core_init().
> >
> > With arch_zone_limits_init() helper available now on all architectures it
> > is no longer necessary to call free_area_init() from architecture setup
> > code. Rather core MM initialization can call arch_zone_limits_init() in a
> > single place.
> >
> > This allows to unify ordering of hugetlb vs memory map allocation and
> > initialization.
> >
> > Remove the call to free_area_init() from architecture specific code and
> > place it in a new mm_core_init_early() function that is called immediately
> > after setup_arch().
> >
> > After this refactoring it is possible to consolidate hugetlb allocations
> > and eliminate differences in ordering of hugetlb and memory map
> > initialization among different architectures.
> >
> > As the first step of this consolidation move hugetlb_bootmem_alloc() to
> > mm_core_early_init().
> >
> > Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
>
> This breaks boot on my Raspberry Pi 1. The reason seems to be the use of
> page_folio() when initializing the dynamically allocated zero page in
> arm, which doesn't work when free_area_init() hasn't been called yet.
I believe the reason is rather the use of virt_to_phys() that now happens
before the memory map is ready.
> The following oopses are generated:
>
> 8<--- cut here ---
> Unable to handle kernel paging request at virtual address 003dfb44 when read
> [003dfb44] *pgd=00000000
> Internal error: Oops: 5 [#1] ARM
> CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.19.0-rc3-03898-g7975b0084358 #451 NONE
> Hardware name: BCM2835
> PC is at paging_init (include/linux/page-flags.h:284 (discriminator 2) arch/arm/mm/mmu.c:1790 (discriminator 2))
> LR is at paging_init (arch/arm/mm/mmu.c:1789 (discriminator 1))
...
> 8<--- cut here ---
>
> and the second one repeats for some time afterwards.
>
> I experimented a little by allocating the zero page statically as many
> other arches do which fixes the issue as it does not need to be
> initialized at this point anymore, though I have no idea if that's
> appropriate.
Do you mean putting the zero in the BSS like, e.g. arm64? I don't see a
reason why this shouldn't work.
I also have a patch with some minor changes that still keeps
empty_zero_page allocated, but avoids virt_to_page() and folio_page()
dance. Can you please test it in your setup?
From 8a213c13211106d592fbe96b68ee29879ed739f8 Mon Sep 17 00:00:00 2001
From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
Date: Sat, 3 Jan 2026 20:40:09 +0200
Subject: [PATCH] arm: make initialization of zero page independent of the
memory map
Unlike most architectures, arm keeps a struct page pointer to the
empty_zero_page and to initialize it requires conversion of a virtual
address to page which makes it necessary to have memory map initialized
before creating the empty_zero_page.
Make empty_zero_page a void * to decouple it's initialization from the
initialization of the memory map.
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
---
arch/arm/include/asm/pgtable.h | 4 ++--
arch/arm/mm/mmu.c | 10 +++-------
arch/arm/mm/nommu.c | 10 +++-------
3 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 86378eec7757..08bbd2aed6c9 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -15,8 +15,8 @@
* ZERO_PAGE is a global shared page that is always zero: used
* for zero-mapped memory areas etc..
*/
-extern struct page *empty_zero_page;
-#define ZERO_PAGE(vaddr) (empty_zero_page)
+extern void *empty_zero_page;
+#define ZERO_PAGE(vaddr) (virt_to_page(empty_zero_page))
#endif
#include <asm-generic/pgtable-nopud.h>
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 8bac96e205ac..867258f1ae09 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -45,7 +45,7 @@ extern unsigned long __atags_pointer;
* empty_zero_page is a special page that is used for
* zero-initialized data and COW.
*/
-struct page *empty_zero_page;
+void *empty_zero_page;
EXPORT_SYMBOL(empty_zero_page);
/*
@@ -1754,8 +1754,6 @@ static void __init early_fixmap_shutdown(void)
*/
void __init paging_init(const struct machine_desc *mdesc)
{
- void *zero_page;
-
#ifdef CONFIG_XIP_KERNEL
/* Store the kernel RW RAM region start/end in these variables */
kernel_sec_start = CONFIG_PHYS_OFFSET & SECTION_MASK;
@@ -1782,12 +1780,10 @@ void __init paging_init(const struct machine_desc *mdesc)
top_pmd = pmd_off_k(0xffff0000);
/* allocate the zero page. */
- zero_page = early_alloc(PAGE_SIZE);
+ empty_zero_page = early_alloc(PAGE_SIZE);
+ __cpuc_flush_dcache_area(empty_zero_page, PAGE_SIZE);
bootmem_init();
-
- empty_zero_page = virt_to_page(zero_page);
- __flush_dcache_folio(NULL, page_folio(empty_zero_page));
}
void __init early_mm_init(const struct machine_desc *mdesc)
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index d638cc87807e..f80ff5a69fbb 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -31,7 +31,7 @@ unsigned long vectors_base;
* empty_zero_page is a special page that is used for
* zero-initialized data and COW.
*/
-struct page *empty_zero_page;
+void *empty_zero_page;
EXPORT_SYMBOL(empty_zero_page);
#ifdef CONFIG_ARM_MPU
@@ -156,18 +156,14 @@ void __init adjust_lowmem_bounds(void)
*/
void __init paging_init(const struct machine_desc *mdesc)
{
- void *zero_page;
-
early_trap_init((void *)vectors_base);
mpu_setup();
/* allocate the zero page. */
- zero_page = (void *)memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
+ empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
+ __cpuc_flush_dcache_area(empty_zero_page, PAGE_SIZE);
bootmem_init();
-
- empty_zero_page = virt_to_page(zero_page);
- flush_dcache_page(empty_zero_page);
}
/*
--
2.51.0
> Regards,
> Klara Modin
>
--
Sincerely yours,
Mike.
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: Klara Modin <klarasmodin@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Alex Shi <alexs@kernel.org>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Andreas Larsson <andreas@gaisler.com>,
Borislav Petkov <bp@alien8.de>, Brian Cain <bcain@kernel.org>,
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
"David S. Miller" <davem@davemloft.net>,
Dave Hansen <dave.hansen@linux.intel.com>,
David Hildenbrand <david@kernel.org>,
Dinh Nguyen <dinguyen@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Guo Ren <guoren@kernel.org>, Heiko Carstens <hca@linux.ibm.com>,
Helge Deller <deller@gmx.de>, Huacai Chen <chenhuacai@kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Johannes Berg <johannes@sipsolutions.net>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Jonathan Corbet <corbet@lwn.net>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Magnus Lindholm <linmag7@gmail.com>,
Matt Turner <mattst88@gmail.com>,
Max Filippov <jcmvbkbc@gmail.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Michal Hocko <mhocko@suse.com>, Michal Simek <monstr@monstr.eu>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
Palmer Dabbelt <palmer@dabbelt.com>,
Pratyush Yadav <pratyush@kernel.org>,
Richard Weinberger <richard@nod.at>,
Russell King <linux@armlinux.org.uk>,
Stafford Horne <shorne@gmail.com>,
Suren Baghdasaryan <surenb@google.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Thomas Gleixner <tglx@linutronix.de>,
Vasily Gorbik <gor@linux.ibm.com>,
Vineet Gupta <vgupta@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>, Will Deacon <will@kernel.org>,
x86@kernel.org, linux-alpha@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org,
linux-cxl@vger.kernel.org, linux-doc@vger.kernel.org,
linux-hexagon@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
linux-mm@kvack.org, linux-openrisc@vger.kernel.org,
linux-parisc@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
linux-snps-arc@lists.infradead.org, linux-um@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev,
sparclinux@vger.kernel.org
Subject: Re: [PATCH v2 22/28] arch, mm: consolidate initialization of nodes, zones and memory map
Date: Sat, 3 Jan 2026 20:54:23 +0200 [thread overview]
Message-ID: <aVll339wim7dCIaQ@kernel.org> (raw)
In-Reply-To: <aVhN2NgQEKe0yzva@soda.int.kasm.eu>
Hi,
On Sat, Jan 03, 2026 at 12:33:29AM +0100, Klara Modin wrote:
> On 2026-01-02 08:59:58 +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
> >
> > To initialize node, zone and memory map data structures every architecture
> > calls free_area_init() during setup_arch() and passes it an array of zone
> > limits.
> >
> > Beside code duplication it creates "interesting" ordering cases between
> > allocation and initialization of hugetlb and the memory map. Some
> > architectures allocate hugetlb pages very early in setup_arch() in certain
> > cases, some only create hugetlb CMA areas in setup_arch() and sometimes
> > hugetlb allocations happen mm_core_init().
> >
> > With arch_zone_limits_init() helper available now on all architectures it
> > is no longer necessary to call free_area_init() from architecture setup
> > code. Rather core MM initialization can call arch_zone_limits_init() in a
> > single place.
> >
> > This allows to unify ordering of hugetlb vs memory map allocation and
> > initialization.
> >
> > Remove the call to free_area_init() from architecture specific code and
> > place it in a new mm_core_init_early() function that is called immediately
> > after setup_arch().
> >
> > After this refactoring it is possible to consolidate hugetlb allocations
> > and eliminate differences in ordering of hugetlb and memory map
> > initialization among different architectures.
> >
> > As the first step of this consolidation move hugetlb_bootmem_alloc() to
> > mm_core_early_init().
> >
> > Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
>
> This breaks boot on my Raspberry Pi 1. The reason seems to be the use of
> page_folio() when initializing the dynamically allocated zero page in
> arm, which doesn't work when free_area_init() hasn't been called yet.
I believe the reason is rather the use of virt_to_phys() that now happens
before the memory map is ready.
> The following oopses are generated:
>
> 8<--- cut here ---
> Unable to handle kernel paging request at virtual address 003dfb44 when read
> [003dfb44] *pgd=00000000
> Internal error: Oops: 5 [#1] ARM
> CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.19.0-rc3-03898-g7975b0084358 #451 NONE
> Hardware name: BCM2835
> PC is at paging_init (include/linux/page-flags.h:284 (discriminator 2) arch/arm/mm/mmu.c:1790 (discriminator 2))
> LR is at paging_init (arch/arm/mm/mmu.c:1789 (discriminator 1))
...
> 8<--- cut here ---
>
> and the second one repeats for some time afterwards.
>
> I experimented a little by allocating the zero page statically as many
> other arches do which fixes the issue as it does not need to be
> initialized at this point anymore, though I have no idea if that's
> appropriate.
Do you mean putting the zero in the BSS like, e.g. arm64? I don't see a
reason why this shouldn't work.
I also have a patch with some minor changes that still keeps
empty_zero_page allocated, but avoids virt_to_page() and folio_page()
dance. Can you please test it in your setup?
From 8a213c13211106d592fbe96b68ee29879ed739f8 Mon Sep 17 00:00:00 2001
From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
Date: Sat, 3 Jan 2026 20:40:09 +0200
Subject: [PATCH] arm: make initialization of zero page independent of the
memory map
Unlike most architectures, arm keeps a struct page pointer to the
empty_zero_page and to initialize it requires conversion of a virtual
address to page which makes it necessary to have memory map initialized
before creating the empty_zero_page.
Make empty_zero_page a void * to decouple it's initialization from the
initialization of the memory map.
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
---
arch/arm/include/asm/pgtable.h | 4 ++--
arch/arm/mm/mmu.c | 10 +++-------
arch/arm/mm/nommu.c | 10 +++-------
3 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 86378eec7757..08bbd2aed6c9 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -15,8 +15,8 @@
* ZERO_PAGE is a global shared page that is always zero: used
* for zero-mapped memory areas etc..
*/
-extern struct page *empty_zero_page;
-#define ZERO_PAGE(vaddr) (empty_zero_page)
+extern void *empty_zero_page;
+#define ZERO_PAGE(vaddr) (virt_to_page(empty_zero_page))
#endif
#include <asm-generic/pgtable-nopud.h>
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 8bac96e205ac..867258f1ae09 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -45,7 +45,7 @@ extern unsigned long __atags_pointer;
* empty_zero_page is a special page that is used for
* zero-initialized data and COW.
*/
-struct page *empty_zero_page;
+void *empty_zero_page;
EXPORT_SYMBOL(empty_zero_page);
/*
@@ -1754,8 +1754,6 @@ static void __init early_fixmap_shutdown(void)
*/
void __init paging_init(const struct machine_desc *mdesc)
{
- void *zero_page;
-
#ifdef CONFIG_XIP_KERNEL
/* Store the kernel RW RAM region start/end in these variables */
kernel_sec_start = CONFIG_PHYS_OFFSET & SECTION_MASK;
@@ -1782,12 +1780,10 @@ void __init paging_init(const struct machine_desc *mdesc)
top_pmd = pmd_off_k(0xffff0000);
/* allocate the zero page. */
- zero_page = early_alloc(PAGE_SIZE);
+ empty_zero_page = early_alloc(PAGE_SIZE);
+ __cpuc_flush_dcache_area(empty_zero_page, PAGE_SIZE);
bootmem_init();
-
- empty_zero_page = virt_to_page(zero_page);
- __flush_dcache_folio(NULL, page_folio(empty_zero_page));
}
void __init early_mm_init(const struct machine_desc *mdesc)
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index d638cc87807e..f80ff5a69fbb 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -31,7 +31,7 @@ unsigned long vectors_base;
* empty_zero_page is a special page that is used for
* zero-initialized data and COW.
*/
-struct page *empty_zero_page;
+void *empty_zero_page;
EXPORT_SYMBOL(empty_zero_page);
#ifdef CONFIG_ARM_MPU
@@ -156,18 +156,14 @@ void __init adjust_lowmem_bounds(void)
*/
void __init paging_init(const struct machine_desc *mdesc)
{
- void *zero_page;
-
early_trap_init((void *)vectors_base);
mpu_setup();
/* allocate the zero page. */
- zero_page = (void *)memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
+ empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
+ __cpuc_flush_dcache_area(empty_zero_page, PAGE_SIZE);
bootmem_init();
-
- empty_zero_page = virt_to_page(zero_page);
- flush_dcache_page(empty_zero_page);
}
/*
--
2.51.0
> Regards,
> Klara Modin
>
--
Sincerely yours,
Mike.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: Klara Modin <klarasmodin@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Alex Shi <alexs@kernel.org>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Andreas Larsson <andreas@gaisler.com>,
Borislav Petkov <bp@alien8.de>, Brian Cain <bcain@kernel.org>,
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
"David S. Miller" <davem@davemloft.net>,
Dave Hansen <dave.hansen@linux.intel.com>,
David Hildenbrand <david@kernel.org>,
Dinh Nguyen <dinguyen@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Guo Ren <guoren@kernel.org>, Heiko Carstens <hca@linux.ibm.com>,
Helge Deller <deller@gmx.de>, Huacai Chen <chenhuacai@kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Johannes Berg <johannes@sipsolutions.net>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Jonathan Corbet <corbet@lwn.net>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Magnus Lindholm <linmag7@gmail.com>,
Matt Turner <mattst88@gmail.com>,
Max Filippov <jcmvbkbc@gmail.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Michal Hocko <mhocko@suse.com>, Michal Simek <monstr@monstr.eu>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
Palmer Dabbelt <palmer@dabbelt.com>,
Pratyush Yadav <pratyush@kernel.org>,
Richard Weinberger <richard@nod.at>,
Russell King <linux@armlinux.org.uk>,
Stafford Horne <shorne@gmail.com>,
Suren Baghdasaryan <surenb@google.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Thomas Gleixner <tglx@linutronix.de>,
Vasily Gorbik <gor@linux.ibm.com>,
Vineet Gupta <vgupta@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>, Will Deacon <will@kernel.org>,
x86@kernel.org, linux-alpha@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org,
linux-cxl@vger.kernel.org, linux-doc@vger.kernel.org,
linux-hexagon@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
linux-mm@kvack.org, linux-openrisc@vger.kernel.org,
linux-parisc@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
linux-snps-arc@lists.infradead.org, linux-um@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev,
sparclinux@vger.kernel.org
Subject: Re: [PATCH v2 22/28] arch, mm: consolidate initialization of nodes, zones and memory map
Date: Sat, 3 Jan 2026 20:54:23 +0200 [thread overview]
Message-ID: <aVll339wim7dCIaQ@kernel.org> (raw)
In-Reply-To: <aVhN2NgQEKe0yzva@soda.int.kasm.eu>
Hi,
On Sat, Jan 03, 2026 at 12:33:29AM +0100, Klara Modin wrote:
> On 2026-01-02 08:59:58 +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
> >
> > To initialize node, zone and memory map data structures every architecture
> > calls free_area_init() during setup_arch() and passes it an array of zone
> > limits.
> >
> > Beside code duplication it creates "interesting" ordering cases between
> > allocation and initialization of hugetlb and the memory map. Some
> > architectures allocate hugetlb pages very early in setup_arch() in certain
> > cases, some only create hugetlb CMA areas in setup_arch() and sometimes
> > hugetlb allocations happen mm_core_init().
> >
> > With arch_zone_limits_init() helper available now on all architectures it
> > is no longer necessary to call free_area_init() from architecture setup
> > code. Rather core MM initialization can call arch_zone_limits_init() in a
> > single place.
> >
> > This allows to unify ordering of hugetlb vs memory map allocation and
> > initialization.
> >
> > Remove the call to free_area_init() from architecture specific code and
> > place it in a new mm_core_init_early() function that is called immediately
> > after setup_arch().
> >
> > After this refactoring it is possible to consolidate hugetlb allocations
> > and eliminate differences in ordering of hugetlb and memory map
> > initialization among different architectures.
> >
> > As the first step of this consolidation move hugetlb_bootmem_alloc() to
> > mm_core_early_init().
> >
> > Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
>
> This breaks boot on my Raspberry Pi 1. The reason seems to be the use of
> page_folio() when initializing the dynamically allocated zero page in
> arm, which doesn't work when free_area_init() hasn't been called yet.
I believe the reason is rather the use of virt_to_phys() that now happens
before the memory map is ready.
> The following oopses are generated:
>
> 8<--- cut here ---
> Unable to handle kernel paging request at virtual address 003dfb44 when read
> [003dfb44] *pgd=00000000
> Internal error: Oops: 5 [#1] ARM
> CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.19.0-rc3-03898-g7975b0084358 #451 NONE
> Hardware name: BCM2835
> PC is at paging_init (include/linux/page-flags.h:284 (discriminator 2) arch/arm/mm/mmu.c:1790 (discriminator 2))
> LR is at paging_init (arch/arm/mm/mmu.c:1789 (discriminator 1))
...
> 8<--- cut here ---
>
> and the second one repeats for some time afterwards.
>
> I experimented a little by allocating the zero page statically as many
> other arches do which fixes the issue as it does not need to be
> initialized at this point anymore, though I have no idea if that's
> appropriate.
Do you mean putting the zero in the BSS like, e.g. arm64? I don't see a
reason why this shouldn't work.
I also have a patch with some minor changes that still keeps
empty_zero_page allocated, but avoids virt_to_page() and folio_page()
dance. Can you please test it in your setup?
From 8a213c13211106d592fbe96b68ee29879ed739f8 Mon Sep 17 00:00:00 2001
From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
Date: Sat, 3 Jan 2026 20:40:09 +0200
Subject: [PATCH] arm: make initialization of zero page independent of the
memory map
Unlike most architectures, arm keeps a struct page pointer to the
empty_zero_page and to initialize it requires conversion of a virtual
address to page which makes it necessary to have memory map initialized
before creating the empty_zero_page.
Make empty_zero_page a void * to decouple it's initialization from the
initialization of the memory map.
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
---
arch/arm/include/asm/pgtable.h | 4 ++--
arch/arm/mm/mmu.c | 10 +++-------
arch/arm/mm/nommu.c | 10 +++-------
3 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 86378eec7757..08bbd2aed6c9 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -15,8 +15,8 @@
* ZERO_PAGE is a global shared page that is always zero: used
* for zero-mapped memory areas etc..
*/
-extern struct page *empty_zero_page;
-#define ZERO_PAGE(vaddr) (empty_zero_page)
+extern void *empty_zero_page;
+#define ZERO_PAGE(vaddr) (virt_to_page(empty_zero_page))
#endif
#include <asm-generic/pgtable-nopud.h>
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 8bac96e205ac..867258f1ae09 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -45,7 +45,7 @@ extern unsigned long __atags_pointer;
* empty_zero_page is a special page that is used for
* zero-initialized data and COW.
*/
-struct page *empty_zero_page;
+void *empty_zero_page;
EXPORT_SYMBOL(empty_zero_page);
/*
@@ -1754,8 +1754,6 @@ static void __init early_fixmap_shutdown(void)
*/
void __init paging_init(const struct machine_desc *mdesc)
{
- void *zero_page;
-
#ifdef CONFIG_XIP_KERNEL
/* Store the kernel RW RAM region start/end in these variables */
kernel_sec_start = CONFIG_PHYS_OFFSET & SECTION_MASK;
@@ -1782,12 +1780,10 @@ void __init paging_init(const struct machine_desc *mdesc)
top_pmd = pmd_off_k(0xffff0000);
/* allocate the zero page. */
- zero_page = early_alloc(PAGE_SIZE);
+ empty_zero_page = early_alloc(PAGE_SIZE);
+ __cpuc_flush_dcache_area(empty_zero_page, PAGE_SIZE);
bootmem_init();
-
- empty_zero_page = virt_to_page(zero_page);
- __flush_dcache_folio(NULL, page_folio(empty_zero_page));
}
void __init early_mm_init(const struct machine_desc *mdesc)
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index d638cc87807e..f80ff5a69fbb 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -31,7 +31,7 @@ unsigned long vectors_base;
* empty_zero_page is a special page that is used for
* zero-initialized data and COW.
*/
-struct page *empty_zero_page;
+void *empty_zero_page;
EXPORT_SYMBOL(empty_zero_page);
#ifdef CONFIG_ARM_MPU
@@ -156,18 +156,14 @@ void __init adjust_lowmem_bounds(void)
*/
void __init paging_init(const struct machine_desc *mdesc)
{
- void *zero_page;
-
early_trap_init((void *)vectors_base);
mpu_setup();
/* allocate the zero page. */
- zero_page = (void *)memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
+ empty_zero_page = memblock_alloc_or_panic(PAGE_SIZE, PAGE_SIZE);
+ __cpuc_flush_dcache_area(empty_zero_page, PAGE_SIZE);
bootmem_init();
-
- empty_zero_page = virt_to_page(zero_page);
- flush_dcache_page(empty_zero_page);
}
/*
--
2.51.0
> Regards,
> Klara Modin
>
--
Sincerely yours,
Mike.
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
next prev parent reply other threads:[~2026-01-03 18:54 UTC|newest]
Thread overview: 132+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-02 6:59 [PATCH v2 00/28] arch, mm: consolidate hugetlb early reservation Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 01/28] alpha: introduce arch_zone_limits_init() Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 02/28] arc: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-08 2:56 ` Vineet Gupta
2026-01-08 2:56 ` Vineet Gupta
2026-01-08 2:56 ` Vineet Gupta
2026-01-02 6:59 ` [PATCH v2 03/28] arm: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 04/28] arm64: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 05/28] csky: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 06/28] hexagon: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 07/28] loongarch: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 08/28] m68k: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 09/28] microblaze: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 10/28] mips: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 11/28] nios2: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 12/28] openrisc: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-03 5:36 ` Stafford Horne
2026-01-03 5:36 ` Stafford Horne
2026-01-03 5:36 ` Stafford Horne
2026-01-02 6:59 ` [PATCH v2 13/28] parisc: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 14/28] powerpc: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-07 4:27 ` Ritesh Harjani
2026-01-07 4:27 ` Ritesh Harjani
2026-01-07 4:27 ` Ritesh Harjani
2026-01-07 10:20 ` Mike Rapoport
2026-01-07 10:20 ` Mike Rapoport
2026-01-07 10:20 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 15/28] riscv: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 16/28] s390: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 17/28] sh: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 18/28] sparc: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 19/28] um: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 20/28] x86: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 21/28] xtensa: " Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 22/28] arch, mm: consolidate initialization of nodes, zones and memory map Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 23:33 ` Klara Modin
2026-01-02 23:33 ` Klara Modin
2026-01-02 23:33 ` Klara Modin
2026-01-03 18:54 ` Mike Rapoport [this message]
2026-01-03 18:54 ` Mike Rapoport
2026-01-03 18:54 ` Mike Rapoport
2026-01-03 20:32 ` Klara Modin
2026-01-03 20:32 ` Klara Modin
2026-01-03 20:32 ` Klara Modin
2026-01-04 12:01 ` [PATCH 3.5] arm: make initialization of zero page independent of the memory map (was Re: [PATCH v2 22/28] arch, mm: consolidate initialization of nodes, zones and memory map) Mike Rapoport
2026-01-04 12:01 ` Mike Rapoport
2026-01-04 12:01 ` Mike Rapoport
2026-01-04 20:56 ` Russell King (Oracle)
2026-01-04 20:56 ` Russell King (Oracle)
2026-01-04 20:56 ` Russell King (Oracle)
2026-01-04 22:07 ` Mike Rapoport
2026-01-04 22:07 ` Mike Rapoport
2026-01-04 22:07 ` Mike Rapoport
2026-01-08 19:19 ` Andrew Morton
2026-01-08 19:19 ` Andrew Morton
2026-01-08 19:19 ` Andrew Morton
2026-02-20 4:11 ` patchwork-bot+linux-riscv
2026-02-20 4:11 ` patchwork-bot+linux-riscv
2026-02-20 4:11 ` patchwork-bot+linux-riscv
2026-01-08 9:24 ` [PATCH v2 22/28] arch, mm: consolidate initialization of nodes, zones and memory map Kalle Niemi
2026-01-08 9:24 ` Kalle Niemi
2026-01-08 9:24 ` Kalle Niemi
2026-01-08 13:37 ` Mike Rapoport
2026-01-08 13:37 ` Mike Rapoport
2026-01-08 13:37 ` Mike Rapoport
2026-01-02 6:59 ` [PATCH v2 23/28] arch, mm: consolidate initialization of SPARSE memory model Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 6:59 ` Mike Rapoport
2026-01-02 7:00 ` [PATCH v2 24/28] mips: drop paging_init() Mike Rapoport
2026-01-02 7:00 ` Mike Rapoport
2026-01-02 7:00 ` Mike Rapoport
2026-01-02 7:00 ` [PATCH v2 25/28] x86: don't reserve hugetlb memory in setup_arch() Mike Rapoport
2026-01-02 7:00 ` Mike Rapoport
2026-01-02 7:00 ` Mike Rapoport
2026-01-02 7:00 ` [PATCH v2 26/28] mm, arch: consolidate hugetlb CMA reservation Mike Rapoport
2026-01-02 7:00 ` Mike Rapoport
2026-01-02 7:00 ` Mike Rapoport
2026-01-02 7:00 ` [PATCH v2 27/28] mm/hugetlb: drop hugetlb_cma_check() Mike Rapoport
2026-01-02 7:00 ` Mike Rapoport
2026-01-02 7:00 ` Mike Rapoport
2026-01-02 7:00 ` [PATCH v2 28/28] Revert "mm/hugetlb: deal with multiple calls to hugetlb_bootmem_alloc" Mike Rapoport
2026-01-02 7:00 ` Mike Rapoport
2026-01-02 7:00 ` Mike Rapoport
2026-01-02 18:03 ` [PATCH v2 00/28] arch, mm: consolidate hugetlb early reservation Frank van der Linden
2026-01-02 18:03 ` Frank van der Linden
2026-01-02 18:03 ` Frank van der Linden
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aVll339wim7dCIaQ@kernel.org \
--to=rppt@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=alexs@kernel.org \
--cc=andreas@gaisler.com \
--cc=bcain@kernel.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=chleroy@kernel.org \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=david@kernel.org \
--cc=deller@gmx.de \
--cc=dinguyen@kernel.org \
--cc=geert@linux-m68k.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=gor@linux.ibm.com \
--cc=guoren@kernel.org \
--cc=hca@linux.ibm.com \
--cc=jcmvbkbc@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=klarasmodin@gmail.com \
--cc=linmag7@gmail.com \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-openrisc@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux-um@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=lorenzo.stoakes@oracle.com \
--cc=mattst88@gmail.com \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=monstr@monstr.eu \
--cc=mpe@ellerman.id.au \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=palmer@dabbelt.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=shorne@gmail.com \
--cc=sparclinux@vger.kernel.org \
--cc=surenb@google.com \
--cc=tglx@linutronix.de \
--cc=tsbogend@alpha.franken.de \
--cc=vbabka@suse.cz \
--cc=vgupta@kernel.org \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.