From: Mike Rapoport <rppt@kernel.org>
To: Andreas Larsson <andreas@gaisler.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Borislav Petkov <bp@alien8.de>, Brian Cain <bcain@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>, 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>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Madhavan Srinivasan <maddy@linux.ibm.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>,
Palmer Dabbelt <palmer@dabbelt.com>,
Richard Weinberger <richard@nod.at>,
Russell King <linux@armlinux.org.uk>,
Stafford Horne <shorne@gmail.com>,
Suren Baghdasaryan <surenb@google.com>,
Thomas Gleixner <tglx@kernel.org>,
Vineet Gupta <vgupta@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>, Will Deacon <will@kernel.org>,
linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org,
linux-hexagon@vger.kernel.org, loongarch@lists.linux.dev,
linux-m68k@lists.linux-m68k.org, linux-openrisc@vger.kernel.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-sh@vger.kernel.org,
sparclinux@vger.kernel.org, linux-um@lists.infradead.org,
linux-mm@kvack.org, x86@kernel.org
Subject: Re: [PATCH mm-unstable] arch, mm: consolidate empty_zero_page
Date: Sat, 7 Feb 2026 12:36:43 +0200 [thread overview]
Message-ID: <aYcVu7gs65S1CeST@kernel.org> (raw)
In-Reply-To: <ec965a79-dad8-4358-a8e9-ebc9f330b67b@gaisler.com>
On Tue, Feb 03, 2026 at 11:17:08AM +0100, Andreas Larsson wrote:
> On 2026-01-27 19:11, Mike Rapoport wrote:
> > On Tue, Jan 27, 2026 at 05:02:39PM +0100, Andreas Larsson wrote:
> >> On 2026-01-24 10:56, Mike Rapoport wrote:
> >>
> >>> Every architecture defines empty_zero_page that way or another, but for the
> >>> most of them it is always a page aligned page in BSS and most definitions
> >>> of ZERO_PAGE do virt_to_page(empty_zero_page).
> >>
> >> Running this in an LDOM on an UltraSparc T4 sparc64, the entire LDOM
> >> hangs after a while during boot.
> >>
> >>> diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> >>> index c2d19c9a9244..2bd99944176d 100644
> >>> --- a/arch/sparc/mm/init_64.c
> >>> +++ b/arch/sparc/mm/init_64.c
> >>> @@ -177,9 +177,6 @@ extern unsigned long sparc_ramdisk_image64;
> >>> extern unsigned int sparc_ramdisk_image;
> >>> extern unsigned int sparc_ramdisk_size;
> >>>
> >>> -struct page *mem_map_zero __read_mostly;
> >>> -EXPORT_SYMBOL(mem_map_zero);
> >>> -
> >>> unsigned int sparc64_highest_unlocked_tlb_ent __read_mostly;
> >>>
> >>> unsigned long sparc64_kern_pri_context __read_mostly;
> >>> @@ -2506,18 +2503,6 @@ void __init mem_init(void)
> >>> */
> >>> register_page_bootmem_info();
> >>>
> >>> - /*
> >>> - * Set up the zero page, mark it reserved, so that page count
> >>> - * is not manipulated when freeing the page from user ptes.
> >>> - */
> >>> - mem_map_zero = alloc_pages(GFP_KERNEL|__GFP_ZERO, 0);
> >>> - if (mem_map_zero == NULL) {
> >>> - prom_printf("paging_init: Cannot alloc zero page.\n");
> >>> - prom_halt();
> >>> - }
> >>> - mark_page_reserved(mem_map_zero);
> >>> -
> >>> -
> >>> if (tlb_type == cheetah || tlb_type == cheetah_plus)
> >>> cheetah_ecache_flush_init();
> >>> }
> >>
> >> This just removes the mark_page_reserved(mem_map_zero) without
> >> replacing it with something corresponding to that. Perhaps part
> >> of the problem?
> >
> > I don't think so, empty_zero_page is in BSS now an it's reserved as a part
> > of the kernel image.
> >
> > I suspect that virt_to_page() does not work BSS symbols on sparc64. Can you
> > please try with this patch:
> >
> > diff --git a/arch/sparc/include/asm/pgtable_64.h b/arch/sparc/include/asm/pgtable_64.h
> > index 74ede706fb32..0578c5172d4e 100644
> > --- a/arch/sparc/include/asm/pgtable_64.h
> > +++ b/arch/sparc/include/asm/pgtable_64.h
> > @@ -22,6 +22,7 @@
> > #include <asm/adi.h>
> > #include <asm/page.h>
> > #include <asm/processor.h>
> > +#include <asm/vaddrs.h>
> >
> > /* The kernel image occupies 0x4000000 to 0x6000000 (4MB --> 96MB).
> > * The page copy blockops can use 0x6000000 to 0x8000000.
> > @@ -210,6 +211,11 @@ extern unsigned long _PAGE_CACHE;
> > extern unsigned long pg_iobits;
> > extern unsigned long _PAGE_ALL_SZ_BITS;
> >
> > +extern unsigned long kern_base;
> > +#define ZERO_PAGE(vaddr) \
> > + (virt_to_page(empty_zero_page + ((unsigned long)__va(kern_base)) - \
> > + ((unsigned long)KERNBASE)))
> > +
> > /* PFNs are real physical page numbers. However, mem_map only begins to record
> > * per-page information starting at pfn_base. This is to handle systems where
> > * the first physical page in the machine is at some huge physical address,
> > diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> > index 2bd99944176d..d2d724ba4f83 100644
> > --- a/arch/sparc/mm/init_64.c
> > +++ b/arch/sparc/mm/init_64.c
> > @@ -170,6 +170,8 @@ static void __init read_obp_memory(const char *property,
> >
> > /* Kernel physical address base and size in bytes. */
> > unsigned long kern_base __read_mostly;
> > +EXPORT_SYMBOL(kern_base);
> > +
> > unsigned long kern_size __read_mostly;
> >
> > /* Initial ramdisk setup */
> Hi,
>
> Unfortunately, that does not help. The LDOM goes down in the same fashion.
Apparently something is wrong with my pointer arithmetics :/
Can you try this one instead?
diff --git a/arch/sparc/include/asm/pgtable_64.h b/arch/sparc/include/asm/pgtable_64.h
index 74ede706fb32..615f460c50af 100644
--- a/arch/sparc/include/asm/pgtable_64.h
+++ b/arch/sparc/include/asm/pgtable_64.h
@@ -210,6 +210,9 @@ extern unsigned long _PAGE_CACHE;
extern unsigned long pg_iobits;
extern unsigned long _PAGE_ALL_SZ_BITS;
+extern struct page *mem_map_zero;
+#define ZERO_PAGE(vaddr) (mem_map_zero)
+
/* PFNs are real physical page numbers. However, mem_map only begins to record
* per-page information starting at pfn_base. This is to handle systems where
* the first physical page in the machine is at some huge physical address,
diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index 2bd99944176d..aa1f9f071fb2 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -177,6 +177,9 @@ extern unsigned long sparc_ramdisk_image64;
extern unsigned int sparc_ramdisk_image;
extern unsigned int sparc_ramdisk_size;
+struct page *mem_map_zero __read_mostly;
+EXPORT_SYMBOL(mem_map_zero);
+
unsigned int sparc64_highest_unlocked_tlb_ent __read_mostly;
unsigned long sparc64_kern_pri_context __read_mostly;
@@ -2495,6 +2498,9 @@ static void __init register_page_bootmem_info(void)
}
void __init mem_init(void)
{
+ phys_addr_t zero_page_pa = kern_base +
+ ((unsigned long)&empty_zero_page[0] - KERNBASE);
+
/*
* Must be done after boot memory is put on freelist, because here we
* might set fields in deferred struct pages that have not yet been
@@ -2503,6 +2509,12 @@ void __init mem_init(void)
*/
register_page_bootmem_info();
+ /*
+ * Set up the zero page, mark it reserved, so that page count
+ * is not manipulated when freeing the page from user ptes.
+ */
+ mem_map_zero = pfn_to_page(PHYS_PFN(zero_page_pa));
+
if (tlb_type == cheetah || tlb_type == cheetah_plus)
cheetah_ecache_flush_init();
}
--
Sincerely yours,
Mike.
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: Andreas Larsson <andreas@gaisler.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Borislav Petkov <bp@alien8.de>, Brian Cain <bcain@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>, 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>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Madhavan Srinivasan <maddy@linux.ibm.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>,
Palmer Dabbelt <palmer@dabbelt.com>,
Richard Weinberger <richard@nod.at>,
Russell King <linux@armlinux.org.uk>,
Stafford Horne <shorne@gmail.com>,
Suren Baghdasaryan <surenb@google.com>,
Thomas Gleixner <tglx@kernel.org>,
Vineet Gupta <vgupta@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>, Will Deacon <will@kernel.org>,
linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org,
linux-hexagon@vger.kernel.org, loongarch@lists.linux.dev,
linux-m68k@lists.linux-m68k.org, linux-openrisc@vger.kernel.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-sh@vger.kernel.org,
sparclinux@vger.kernel.org, linux-um@lists.infradead.org,
linux-mm@kvack.org, x86@kernel.org
Subject: Re: [PATCH mm-unstable] arch, mm: consolidate empty_zero_page
Date: Sat, 7 Feb 2026 12:36:43 +0200 [thread overview]
Message-ID: <aYcVu7gs65S1CeST@kernel.org> (raw)
In-Reply-To: <ec965a79-dad8-4358-a8e9-ebc9f330b67b@gaisler.com>
On Tue, Feb 03, 2026 at 11:17:08AM +0100, Andreas Larsson wrote:
> On 2026-01-27 19:11, Mike Rapoport wrote:
> > On Tue, Jan 27, 2026 at 05:02:39PM +0100, Andreas Larsson wrote:
> >> On 2026-01-24 10:56, Mike Rapoport wrote:
> >>
> >>> Every architecture defines empty_zero_page that way or another, but for the
> >>> most of them it is always a page aligned page in BSS and most definitions
> >>> of ZERO_PAGE do virt_to_page(empty_zero_page).
> >>
> >> Running this in an LDOM on an UltraSparc T4 sparc64, the entire LDOM
> >> hangs after a while during boot.
> >>
> >>> diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> >>> index c2d19c9a9244..2bd99944176d 100644
> >>> --- a/arch/sparc/mm/init_64.c
> >>> +++ b/arch/sparc/mm/init_64.c
> >>> @@ -177,9 +177,6 @@ extern unsigned long sparc_ramdisk_image64;
> >>> extern unsigned int sparc_ramdisk_image;
> >>> extern unsigned int sparc_ramdisk_size;
> >>>
> >>> -struct page *mem_map_zero __read_mostly;
> >>> -EXPORT_SYMBOL(mem_map_zero);
> >>> -
> >>> unsigned int sparc64_highest_unlocked_tlb_ent __read_mostly;
> >>>
> >>> unsigned long sparc64_kern_pri_context __read_mostly;
> >>> @@ -2506,18 +2503,6 @@ void __init mem_init(void)
> >>> */
> >>> register_page_bootmem_info();
> >>>
> >>> - /*
> >>> - * Set up the zero page, mark it reserved, so that page count
> >>> - * is not manipulated when freeing the page from user ptes.
> >>> - */
> >>> - mem_map_zero = alloc_pages(GFP_KERNEL|__GFP_ZERO, 0);
> >>> - if (mem_map_zero == NULL) {
> >>> - prom_printf("paging_init: Cannot alloc zero page.\n");
> >>> - prom_halt();
> >>> - }
> >>> - mark_page_reserved(mem_map_zero);
> >>> -
> >>> -
> >>> if (tlb_type == cheetah || tlb_type == cheetah_plus)
> >>> cheetah_ecache_flush_init();
> >>> }
> >>
> >> This just removes the mark_page_reserved(mem_map_zero) without
> >> replacing it with something corresponding to that. Perhaps part
> >> of the problem?
> >
> > I don't think so, empty_zero_page is in BSS now an it's reserved as a part
> > of the kernel image.
> >
> > I suspect that virt_to_page() does not work BSS symbols on sparc64. Can you
> > please try with this patch:
> >
> > diff --git a/arch/sparc/include/asm/pgtable_64.h b/arch/sparc/include/asm/pgtable_64.h
> > index 74ede706fb32..0578c5172d4e 100644
> > --- a/arch/sparc/include/asm/pgtable_64.h
> > +++ b/arch/sparc/include/asm/pgtable_64.h
> > @@ -22,6 +22,7 @@
> > #include <asm/adi.h>
> > #include <asm/page.h>
> > #include <asm/processor.h>
> > +#include <asm/vaddrs.h>
> >
> > /* The kernel image occupies 0x4000000 to 0x6000000 (4MB --> 96MB).
> > * The page copy blockops can use 0x6000000 to 0x8000000.
> > @@ -210,6 +211,11 @@ extern unsigned long _PAGE_CACHE;
> > extern unsigned long pg_iobits;
> > extern unsigned long _PAGE_ALL_SZ_BITS;
> >
> > +extern unsigned long kern_base;
> > +#define ZERO_PAGE(vaddr) \
> > + (virt_to_page(empty_zero_page + ((unsigned long)__va(kern_base)) - \
> > + ((unsigned long)KERNBASE)))
> > +
> > /* PFNs are real physical page numbers. However, mem_map only begins to record
> > * per-page information starting at pfn_base. This is to handle systems where
> > * the first physical page in the machine is at some huge physical address,
> > diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> > index 2bd99944176d..d2d724ba4f83 100644
> > --- a/arch/sparc/mm/init_64.c
> > +++ b/arch/sparc/mm/init_64.c
> > @@ -170,6 +170,8 @@ static void __init read_obp_memory(const char *property,
> >
> > /* Kernel physical address base and size in bytes. */
> > unsigned long kern_base __read_mostly;
> > +EXPORT_SYMBOL(kern_base);
> > +
> > unsigned long kern_size __read_mostly;
> >
> > /* Initial ramdisk setup */
> Hi,
>
> Unfortunately, that does not help. The LDOM goes down in the same fashion.
Apparently something is wrong with my pointer arithmetics :/
Can you try this one instead?
diff --git a/arch/sparc/include/asm/pgtable_64.h b/arch/sparc/include/asm/pgtable_64.h
index 74ede706fb32..615f460c50af 100644
--- a/arch/sparc/include/asm/pgtable_64.h
+++ b/arch/sparc/include/asm/pgtable_64.h
@@ -210,6 +210,9 @@ extern unsigned long _PAGE_CACHE;
extern unsigned long pg_iobits;
extern unsigned long _PAGE_ALL_SZ_BITS;
+extern struct page *mem_map_zero;
+#define ZERO_PAGE(vaddr) (mem_map_zero)
+
/* PFNs are real physical page numbers. However, mem_map only begins to record
* per-page information starting at pfn_base. This is to handle systems where
* the first physical page in the machine is at some huge physical address,
diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index 2bd99944176d..aa1f9f071fb2 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -177,6 +177,9 @@ extern unsigned long sparc_ramdisk_image64;
extern unsigned int sparc_ramdisk_image;
extern unsigned int sparc_ramdisk_size;
+struct page *mem_map_zero __read_mostly;
+EXPORT_SYMBOL(mem_map_zero);
+
unsigned int sparc64_highest_unlocked_tlb_ent __read_mostly;
unsigned long sparc64_kern_pri_context __read_mostly;
@@ -2495,6 +2498,9 @@ static void __init register_page_bootmem_info(void)
}
void __init mem_init(void)
{
+ phys_addr_t zero_page_pa = kern_base +
+ ((unsigned long)&empty_zero_page[0] - KERNBASE);
+
/*
* Must be done after boot memory is put on freelist, because here we
* might set fields in deferred struct pages that have not yet been
@@ -2503,6 +2509,12 @@ void __init mem_init(void)
*/
register_page_bootmem_info();
+ /*
+ * Set up the zero page, mark it reserved, so that page count
+ * is not manipulated when freeing the page from user ptes.
+ */
+ mem_map_zero = pfn_to_page(PHYS_PFN(zero_page_pa));
+
if (tlb_type == cheetah || tlb_type == cheetah_plus)
cheetah_ecache_flush_init();
}
--
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: Andreas Larsson <andreas@gaisler.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Borislav Petkov <bp@alien8.de>, Brian Cain <bcain@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>, 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>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Madhavan Srinivasan <maddy@linux.ibm.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>,
Palmer Dabbelt <palmer@dabbelt.com>,
Richard Weinberger <richard@nod.at>,
Russell King <linux@armlinux.org.uk>,
Stafford Horne <shorne@gmail.com>,
Suren Baghdasaryan <surenb@google.com>,
Thomas Gleixner <tglx@kernel.org>,
Vineet Gupta <vgupta@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>, Will Deacon <will@kernel.org>,
linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org,
linux-hexagon@vger.kernel.org, loongarch@lists.linux.dev,
linux-m68k@lists.linux-m68k.org, linux-openrisc@vger.kernel.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-sh@vger.kernel.org,
sparclinux@vger.kernel.org, linux-um@lists.infradead.org,
linux-mm@kvack.org, x86@kernel.org
Subject: Re: [PATCH mm-unstable] arch, mm: consolidate empty_zero_page
Date: Sat, 7 Feb 2026 12:36:43 +0200 [thread overview]
Message-ID: <aYcVu7gs65S1CeST@kernel.org> (raw)
In-Reply-To: <ec965a79-dad8-4358-a8e9-ebc9f330b67b@gaisler.com>
On Tue, Feb 03, 2026 at 11:17:08AM +0100, Andreas Larsson wrote:
> On 2026-01-27 19:11, Mike Rapoport wrote:
> > On Tue, Jan 27, 2026 at 05:02:39PM +0100, Andreas Larsson wrote:
> >> On 2026-01-24 10:56, Mike Rapoport wrote:
> >>
> >>> Every architecture defines empty_zero_page that way or another, but for the
> >>> most of them it is always a page aligned page in BSS and most definitions
> >>> of ZERO_PAGE do virt_to_page(empty_zero_page).
> >>
> >> Running this in an LDOM on an UltraSparc T4 sparc64, the entire LDOM
> >> hangs after a while during boot.
> >>
> >>> diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> >>> index c2d19c9a9244..2bd99944176d 100644
> >>> --- a/arch/sparc/mm/init_64.c
> >>> +++ b/arch/sparc/mm/init_64.c
> >>> @@ -177,9 +177,6 @@ extern unsigned long sparc_ramdisk_image64;
> >>> extern unsigned int sparc_ramdisk_image;
> >>> extern unsigned int sparc_ramdisk_size;
> >>>
> >>> -struct page *mem_map_zero __read_mostly;
> >>> -EXPORT_SYMBOL(mem_map_zero);
> >>> -
> >>> unsigned int sparc64_highest_unlocked_tlb_ent __read_mostly;
> >>>
> >>> unsigned long sparc64_kern_pri_context __read_mostly;
> >>> @@ -2506,18 +2503,6 @@ void __init mem_init(void)
> >>> */
> >>> register_page_bootmem_info();
> >>>
> >>> - /*
> >>> - * Set up the zero page, mark it reserved, so that page count
> >>> - * is not manipulated when freeing the page from user ptes.
> >>> - */
> >>> - mem_map_zero = alloc_pages(GFP_KERNEL|__GFP_ZERO, 0);
> >>> - if (mem_map_zero == NULL) {
> >>> - prom_printf("paging_init: Cannot alloc zero page.\n");
> >>> - prom_halt();
> >>> - }
> >>> - mark_page_reserved(mem_map_zero);
> >>> -
> >>> -
> >>> if (tlb_type == cheetah || tlb_type == cheetah_plus)
> >>> cheetah_ecache_flush_init();
> >>> }
> >>
> >> This just removes the mark_page_reserved(mem_map_zero) without
> >> replacing it with something corresponding to that. Perhaps part
> >> of the problem?
> >
> > I don't think so, empty_zero_page is in BSS now an it's reserved as a part
> > of the kernel image.
> >
> > I suspect that virt_to_page() does not work BSS symbols on sparc64. Can you
> > please try with this patch:
> >
> > diff --git a/arch/sparc/include/asm/pgtable_64.h b/arch/sparc/include/asm/pgtable_64.h
> > index 74ede706fb32..0578c5172d4e 100644
> > --- a/arch/sparc/include/asm/pgtable_64.h
> > +++ b/arch/sparc/include/asm/pgtable_64.h
> > @@ -22,6 +22,7 @@
> > #include <asm/adi.h>
> > #include <asm/page.h>
> > #include <asm/processor.h>
> > +#include <asm/vaddrs.h>
> >
> > /* The kernel image occupies 0x4000000 to 0x6000000 (4MB --> 96MB).
> > * The page copy blockops can use 0x6000000 to 0x8000000.
> > @@ -210,6 +211,11 @@ extern unsigned long _PAGE_CACHE;
> > extern unsigned long pg_iobits;
> > extern unsigned long _PAGE_ALL_SZ_BITS;
> >
> > +extern unsigned long kern_base;
> > +#define ZERO_PAGE(vaddr) \
> > + (virt_to_page(empty_zero_page + ((unsigned long)__va(kern_base)) - \
> > + ((unsigned long)KERNBASE)))
> > +
> > /* PFNs are real physical page numbers. However, mem_map only begins to record
> > * per-page information starting at pfn_base. This is to handle systems where
> > * the first physical page in the machine is at some huge physical address,
> > diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> > index 2bd99944176d..d2d724ba4f83 100644
> > --- a/arch/sparc/mm/init_64.c
> > +++ b/arch/sparc/mm/init_64.c
> > @@ -170,6 +170,8 @@ static void __init read_obp_memory(const char *property,
> >
> > /* Kernel physical address base and size in bytes. */
> > unsigned long kern_base __read_mostly;
> > +EXPORT_SYMBOL(kern_base);
> > +
> > unsigned long kern_size __read_mostly;
> >
> > /* Initial ramdisk setup */
> Hi,
>
> Unfortunately, that does not help. The LDOM goes down in the same fashion.
Apparently something is wrong with my pointer arithmetics :/
Can you try this one instead?
diff --git a/arch/sparc/include/asm/pgtable_64.h b/arch/sparc/include/asm/pgtable_64.h
index 74ede706fb32..615f460c50af 100644
--- a/arch/sparc/include/asm/pgtable_64.h
+++ b/arch/sparc/include/asm/pgtable_64.h
@@ -210,6 +210,9 @@ extern unsigned long _PAGE_CACHE;
extern unsigned long pg_iobits;
extern unsigned long _PAGE_ALL_SZ_BITS;
+extern struct page *mem_map_zero;
+#define ZERO_PAGE(vaddr) (mem_map_zero)
+
/* PFNs are real physical page numbers. However, mem_map only begins to record
* per-page information starting at pfn_base. This is to handle systems where
* the first physical page in the machine is at some huge physical address,
diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index 2bd99944176d..aa1f9f071fb2 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -177,6 +177,9 @@ extern unsigned long sparc_ramdisk_image64;
extern unsigned int sparc_ramdisk_image;
extern unsigned int sparc_ramdisk_size;
+struct page *mem_map_zero __read_mostly;
+EXPORT_SYMBOL(mem_map_zero);
+
unsigned int sparc64_highest_unlocked_tlb_ent __read_mostly;
unsigned long sparc64_kern_pri_context __read_mostly;
@@ -2495,6 +2498,9 @@ static void __init register_page_bootmem_info(void)
}
void __init mem_init(void)
{
+ phys_addr_t zero_page_pa = kern_base +
+ ((unsigned long)&empty_zero_page[0] - KERNBASE);
+
/*
* Must be done after boot memory is put on freelist, because here we
* might set fields in deferred struct pages that have not yet been
@@ -2503,6 +2509,12 @@ void __init mem_init(void)
*/
register_page_bootmem_info();
+ /*
+ * Set up the zero page, mark it reserved, so that page count
+ * is not manipulated when freeing the page from user ptes.
+ */
+ mem_map_zero = pfn_to_page(PHYS_PFN(zero_page_pa));
+
if (tlb_type == cheetah || tlb_type == cheetah_plus)
cheetah_ecache_flush_init();
}
--
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-02-07 10:37 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-24 9:56 [PATCH mm-unstable] arch, mm: consolidate empty_zero_page Mike Rapoport
2026-01-24 9:56 ` Mike Rapoport
2026-01-24 9:56 ` Mike Rapoport
2026-01-24 10:15 ` Christophe Leroy (CS GROUP)
2026-01-24 10:15 ` Christophe Leroy (CS GROUP)
2026-01-24 10:15 ` Christophe Leroy (CS GROUP)
2026-01-27 16:02 ` Andreas Larsson
2026-01-27 16:02 ` Andreas Larsson
2026-01-27 16:02 ` Andreas Larsson
2026-01-27 18:11 ` Mike Rapoport
2026-01-27 18:11 ` Mike Rapoport
2026-01-27 18:11 ` Mike Rapoport
2026-02-03 10:17 ` Andreas Larsson
2026-02-03 10:17 ` Andreas Larsson
2026-02-03 10:17 ` Andreas Larsson
2026-02-07 10:36 ` Mike Rapoport [this message]
2026-02-07 10:36 ` Mike Rapoport
2026-02-07 10:36 ` Mike Rapoport
2026-02-09 8:41 ` Andreas Larsson
2026-02-09 8:41 ` Andreas Larsson
2026-02-09 8:41 ` Andreas Larsson
2026-02-04 20:47 ` David Hildenbrand (arm)
2026-02-04 20:47 ` David Hildenbrand (arm)
2026-02-04 20:47 ` David Hildenbrand (arm)
2026-02-07 2:13 ` Helge Deller
2026-02-07 2:13 ` Helge Deller
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=aYcVu7gs65S1CeST@kernel.org \
--to=rppt@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=andreas@gaisler.com \
--cc=bcain@kernel.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--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=guoren@kernel.org \
--cc=jcmvbkbc@gmail.com \
--cc=johannes@sipsolutions.net \
--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-hexagon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.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-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=maddy@linux.ibm.com \
--cc=mattst88@gmail.com \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=monstr@monstr.eu \
--cc=mpe@ellerman.id.au \
--cc=palmer@dabbelt.com \
--cc=richard@nod.at \
--cc=shorne@gmail.com \
--cc=sparclinux@vger.kernel.org \
--cc=surenb@google.com \
--cc=tglx@kernel.org \
--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.