| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAPTztWaZZt_ygCDNaDdW9A_TtT1FNZW6hFzyiq2b6_xxMw38gQ@mail.gmail.com> Date: Fri, 2 Jan 2026 10:03:49 -0800 From: Frank van der Linden <fvdl@...gle.com> To: Mike Rapoport <rppt@...nel.org> Cc: Andrew Morton <akpm@...ux-foundation.org>, Alex Shi <alexs@...nel.org>, Alexander Gordeev <agordeev@...ux.ibm.com>, Andreas Larsson <andreas@...sler.com>, Borislav Petkov <bp@...en8.de>, Brian Cain <bcain@...nel.org>, "Christophe Leroy (CS GROUP)" <chleroy@...nel.org>, Catalin Marinas <catalin.marinas@....com>, "David S. Miller" <davem@...emloft.net>, Dave Hansen <dave.hansen@...ux.intel.com>, David Hildenbrand <david@...nel.org>, Dinh Nguyen <dinguyen@...nel.org>, Geert Uytterhoeven <geert@...ux-m68k.org>, Guo Ren <guoren@...nel.org>, Heiko Carstens <hca@...ux.ibm.com>, Helge Deller <deller@....de>, Huacai Chen <chenhuacai@...nel.org>, Ingo Molnar <mingo@...hat.com>, Johannes Berg <johannes@...solutions.net>, John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, Jonathan Corbet <corbet@....net>, "Liam R. Howlett" <Liam.Howlett@...cle.com>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Magnus Lindholm <linmag7@...il.com>, Matt Turner <mattst88@...il.com>, Max Filippov <jcmvbkbc@...il.com>, Michael Ellerman <mpe@...erman.id.au>, Michal Hocko <mhocko@...e.com>, Michal Simek <monstr@...str.eu>, Muchun Song <muchun.song@...ux.dev>, Oscar Salvador <osalvador@...e.de>, Palmer Dabbelt <palmer@...belt.com>, Pratyush Yadav <pratyush@...nel.org>, Richard Weinberger <richard@....at>, Russell King <linux@...linux.org.uk>, Stafford Horne <shorne@...il.com>, Suren Baghdasaryan <surenb@...gle.com>, Thomas Bogendoerfer <tsbogend@...ha.franken.de>, Thomas Gleixner <tglx@...utronix.de>, Vasily Gorbik <gor@...ux.ibm.com>, Vineet Gupta <vgupta@...nel.org>, Vlastimil Babka <vbabka@...e.cz>, Will Deacon <will@...nel.org>, x86@...nel.org, linux-alpha@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, linux-csky@...r.kernel.org, linux-cxl@...r.kernel.org, linux-doc@...r.kernel.org, linux-hexagon@...r.kernel.org, linux-kernel@...r.kernel.org, linux-m68k@...ts.linux-m68k.org, linux-mips@...r.kernel.org, linux-mm@...ck.org, linux-openrisc@...r.kernel.org, linux-parisc@...r.kernel.org, linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org, linux-sh@...r.kernel.org, linux-snps-arc@...ts.infradead.org, linux-um@...ts.infradead.org, linuxppc-dev@...ts.ozlabs.org, loongarch@...ts.linux.dev, sparclinux@...r.kernel.org Subject: Re: [PATCH v2 00/28] arch, mm: consolidate hugetlb early reservation On Thu, Jan 1, 2026 at 11:00 PM Mike Rapoport <rppt@...nel.org> wrote: > > From: "Mike Rapoport (Microsoft)" <rppt@...nel.org> > > Hi, > > Order in which early memory reservation for hugetlb happens depends on > architecture, on configuration options and on command line parameters. > > Some architectures rely on the core MM to call hugetlb_bootmem_alloc() > while others call it very early to allow pre-allocation of HVO-style > vmemmap. > > When hugetlb_cma is supported by an architecture it is initialized during > setup_arch() and then later hugetlb_init code needs to understand did it > happen or not. > > To make everything consistent and unified, both reservation of hugetlb > memory from bootmem and creation of CMA areas for hugetlb must be called > from core MM initialization and it would have been a simple change. > However, HVO-style pre-initialization ordering requirements slightly > complicate things and for HVO pre-init to work sparse and memory map should > be initialized after hugetlb reservations. > > This required pulling out the call to free_area_init() out of setup_arch() > path and moving it MM initialization and this is what the first 23 patches > do. > > These changes are deliberately split into per-arch patches that change how > the zone limits are calculated for each architecture and the patches 22 and > 23 just remove the calls to free_area_init() and sprase_init() from arch/*. > > Patch 24 is a simple cleanup for MIPS. > > Patches 25 and 26 actually consolidate hugetlb reservations and patches 27 > and 28 perform some aftermath cleanups. > > I tried to trim the distribution list and although it's still quite long > if you feel that someone was wrongly excluded please add them back. > > The changes also available in git: > https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git/log/?h=hugetlb-init/v2 > > v2 changes: > * move the hugetlb and memory map initializaion to mm_core_init_early() > * add Acks > > v1: https://lore.kernel.org/all/20251228124001.3624742-1-rppt@kernel.org > > Mike Rapoport (Microsoft) (28): > alpha: introduce arch_zone_limits_init() > arc: introduce arch_zone_limits_init() > arm: introduce arch_zone_limits_init() > arm64: introduce arch_zone_limits_init() > csky: introduce arch_zone_limits_init() > hexagon: introduce arch_zone_limits_init() > loongarch: introduce arch_zone_limits_init() > m68k: introduce arch_zone_limits_init() > microblaze: introduce arch_zone_limits_init() > mips: introduce arch_zone_limits_init() > nios2: introduce arch_zone_limits_init() > openrisc: introduce arch_zone_limits_init() > parisc: introduce arch_zone_limits_init() > powerpc: introduce arch_zone_limits_init() > riscv: introduce arch_zone_limits_init() > s390: introduce arch_zone_limits_init() > sh: introduce arch_zone_limits_init() > sparc: introduce arch_zone_limits_init() > um: introduce arch_zone_limits_init() > x86: introduce arch_zone_limits_init() > xtensa: introduce arch_zone_limits_init() > arch, mm: consolidate initialization of nodes, zones and memory map > arch, mm: consolidate initialization of SPARSE memory model > mips: drop paging_init() > x86: don't reserve hugetlb memory in setup_arch() > mm, arch: consolidate hugetlb CMA reservation > mm/hugetlb: drop hugetlb_cma_check() > Revert "mm/hugetlb: deal with multiple calls to hugetlb_bootmem_alloc" > > .../driver-api/cxl/linux/early-boot.rst | 2 +- > Documentation/mm/memory-model.rst | 3 -- > .../translations/zh_CN/mm/memory-model.rst | 2 - > arch/alpha/kernel/setup.c | 1 - > arch/alpha/mm/init.c | 16 ++++---- > arch/arc/mm/init.c | 37 +++++++++--------- > arch/arm/mm/init.c | 25 ++---------- > arch/arm64/include/asm/hugetlb.h | 2 - > arch/arm64/mm/hugetlbpage.c | 10 ++--- > arch/arm64/mm/init.c | 39 ++++++++----------- > arch/csky/kernel/setup.c | 16 ++++---- > arch/hexagon/mm/init.c | 19 +++------ > arch/loongarch/include/asm/pgtable.h | 2 - > arch/loongarch/kernel/setup.c | 10 ----- > arch/loongarch/mm/init.c | 6 +-- > arch/m68k/mm/init.c | 8 ++-- > arch/m68k/mm/mcfmmu.c | 3 -- > arch/m68k/mm/motorola.c | 6 +-- > arch/m68k/mm/sun3mmu.c | 9 ----- > arch/microblaze/mm/init.c | 22 +++++------ > arch/mips/include/asm/pgalloc.h | 2 - > arch/mips/include/asm/pgtable.h | 2 +- > arch/mips/kernel/setup.c | 15 +------ > arch/mips/loongson64/numa.c | 10 ++--- > arch/mips/mm/init.c | 8 +--- > arch/mips/sgi-ip27/ip27-memory.c | 8 +--- > arch/nios2/mm/init.c | 12 +++--- > arch/openrisc/mm/init.c | 10 +---- > arch/parisc/mm/init.c | 11 +----- > arch/powerpc/include/asm/hugetlb.h | 5 --- > arch/powerpc/include/asm/setup.h | 4 ++ > arch/powerpc/kernel/setup-common.c | 1 - > arch/powerpc/mm/hugetlbpage.c | 11 ++---- > arch/powerpc/mm/mem.c | 27 +++++-------- > arch/powerpc/mm/numa.c | 2 - > arch/riscv/mm/hugetlbpage.c | 8 ++++ > arch/riscv/mm/init.c | 10 +---- > arch/s390/kernel/setup.c | 2 - > arch/s390/mm/hugetlbpage.c | 8 ++++ > arch/s390/mm/init.c | 13 +++---- > arch/sh/mm/init.c | 12 +++--- > arch/sparc/mm/init_64.c | 17 +++----- > arch/sparc/mm/srmmu.c | 17 ++++---- > arch/um/kernel/mem.c | 10 ++--- > arch/x86/kernel/setup.c | 5 --- > arch/x86/mm/hugetlbpage.c | 8 ++++ > arch/x86/mm/init.c | 8 +--- > arch/x86/mm/init_32.c | 2 - > arch/x86/mm/init_64.c | 4 -- > arch/x86/mm/mm_internal.h | 1 - > arch/xtensa/mm/init.c | 14 +++---- > include/linux/hugetlb.h | 12 ++---- > include/linux/mm.h | 5 ++- > include/linux/mmzone.h | 2 - > init/main.c | 1 + > mm/hugetlb.c | 13 ------- > mm/hugetlb_cma.c | 33 ++++++++-------- > mm/hugetlb_cma.h | 5 --- > mm/hugetlb_vmemmap.c | 11 ------ > mm/internal.h | 6 +++ > mm/mm_init.c | 20 ++++++---- > 61 files changed, 219 insertions(+), 394 deletions(-) > > > base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 > -- > 2.51.0 > Thanks for this series. When I introduced HVO pre-init, I noticed the inconsistencies in init order, but shied away from attempting any general cleanup, as I had only tested pre-init on x86. With this, it should be possible to enable ARCH_WANT_HUGETLB_VMEMMAP_PREINIT on architectures that support HVO. I think that's only riscv and loongarch right now. But that's out of scope here, though. - Frank
Powered by blists - more mailing lists