Re: [PATCH v3 3/4] arch, mm: consolidate empty_zero_page
Mike Rapoport <[email protected]>
| Newsgroups | gmane.linux.ports.sh.devel,gmane.linux.kernel,gmane.linux.kernel.mm |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Apr 16, 2026 at 10:10:06AM +0200, Thomas WeiÃschuh wrote: > Hi Mike, > > 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)) > Reproducer: > ./tools/testing/kunit/kunit.py run --arch sh --cross_compile sh4-linux- --raw_output=all example > > > * hexagon: had an amusing comment about empty_zero_page > > > > /* A handy thing to have if one has the RAM. Declared in head.S */ > > > > that unfortunately had to go :) > > (...) > > > Thomas -- Sincerely yours, Mike.