Re: [PATCH v3 3/4] arch, mm: consolidate empty_zero_page

On Thu, Apr 16, 2026 at 01:20:17PM +0200, Thomas Weißschuh wrote:
> On Thu, Apr 16, 2026 at 02:02:27PM +0300, Mike Rapoport wrote:
> > On Thu, Apr 16, 2026 at 10:10:06AM +0200, Thomas Weißschuh wrote:
> > > On Wed, Feb 11, 2026 at 12:31:40PM +0200, Mike Rapoport wrote:
> > > > From: "Mike Rapoport (Microsoft)" <[email protected]>
> > > > 
> > > > Reduce 22 declarations of empty_zero_page to 3 and 23 declarations of
> > > > ZERO_PAGE() to 4.
> > > > 
> > > > 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).
> > > > 
> > > > Move Linus vetted x86 definition of empty_zero_page and ZERO_PAGE() to the
> > > > core MM and drop these definitions in architectures that do not implement
> > > > colored zero page (MIPS and s390).
> > > > 
> > > > ZERO_PAGE() remains a macro because turning it to a wrapper for a static
> > > > inline causes severe pain in header dependencies.
> > > > 
> > > > For the most part the change is mechanical, with these being noteworthy:
> > > > 
> > > > * alpha: aliased empty_zero_page with ZERO_PGE that was also used for boot
> > > >   parameters. Switching to a generic empty_zero_page removes the aliasing
> > > >   and keeps ZERO_PGE for boot parameters only
> > > > * arm64: uses __pa_symbol() in ZERO_PAGE() so that definition of
> > > >   ZERO_PAGE() is kept intact.
> > > > * m68k/parisc/um: allocated empty_zero_page from memblock,
> > > >   although they do not support zero page coloring and having it in BSS
> > > >   will work fine.
> > > > * sparc64 can have empty_zero_page in BSS rather allocate it, but it
> > > >   can't use virt_to_page() for BSS. Keep it's definition of ZERO_PAGE()
> > > >   but instead of allocating it, make mem_map_zero point to
> > > >   empty_zero_page.
> > > > * sh: used empty_zero_page for boot parameters at the very early boot.
> > > >   Rename the parameters page to boot_params_page and let sh use the generic
> > > >   empty_zero_page.
> > > 
> > > With this in mainline as commit 6215d9f4470f ("arch, mm: consolidate
> > > empty_zero_page") booting sh on QEMU is now broken.
> > > The machine hangs before any output.
> > 
> > Hmm, looks like sh does not like boot_param_page declared as unsigned char *
> > This fixes the issue for me:
> > 
> > diff --git a/arch/sh/include/asm/setup.h b/arch/sh/include/asm/setup.h
> > index 63c9efc06348..b7c4469cb61e 100644
> > --- a/arch/sh/include/asm/setup.h
> > +++ b/arch/sh/include/asm/setup.h
> > @@ -3,12 +3,13 @@
> >  #define _SH_SETUP_H
> >  
> >  #include <uapi/asm/setup.h>
> > +#include <asm/page.h>
> >  
> >  /*
> >   * This is set up by the setup-routine at boot-time
> >   */
> > -extern unsigned char *boot_params_page;
> > -#define PARAM boot_params_page
> > +extern unsigned long boot_params_page[PAGE_SIZE / sizeof(unsigned long)];
> > +#define PARAM ((unsigned char *)boot_params_page)
> >  
> >  #define MOUNT_ROOT_RDONLY (*(unsigned long *) (PARAM+0x000))
> >  #define RAMDISK_FLAGS (*(unsigned long *) (PARAM+0x004))
> 
> Seems weird but works.

Seems like it's enough to declare boot_params_page as an array, this one
also worked for me:

diff --git a/arch/sh/include/asm/setup.h b/arch/sh/include/asm/setup.h
index 63c9efc06348..8488f76b48b4 100644
--- a/arch/sh/include/asm/setup.h
+++ b/arch/sh/include/asm/setup.h
@@ -7,7 +7,7 @@
 /*
  * This is set up by the setup-routine at boot-time
  */
-extern unsigned char *boot_params_page;
+extern unsigned char boot_params_page[];
 #define PARAM boot_params_page
 
 #define MOUNT_ROOT_RDONLY (*(unsigned long *) (PARAM+0x000))
 

-- 
Sincerely yours,
Mike.