Re: [PATCH v4 00/19] mm: Refactor bootmem gigantic hugepage allocation

[Andrew Morton]

On Fri, 12 Jun 2026 11:58:44 +0800 Muchun Song <songmuchun@xxxxxxxxxxxxx> wrote:

> This series is split out from the earlier larger series "mm: Generalize
> HVO for HugeTLB and device DAX" [1]. It collects the first 19 patches of
> that series as a standalone set of fixes and preparatory cleanups around
> bootmem HugeTLB handling, sparse initialization ordering, and related
> vmemmap setup.
> 
> The first patches fix a few bugs found while reviewing the existing
> code, including incorrect bootmem HVO handling, wrong vmemmap
> registration arguments, a powerpc compound-vmemmap tracking bug, and
> too-late initialization of gigantic bootmem HugeTLB struct pages.
> 
> The rest of the series reorders early memory initialization so the
> relevant zone state is available before sparse and HugeTLB boot-time
> setup runs, then simplifies the remaining bootmem gigantic hugepage
> allocation path and removes code made obsolete by that rework.

Thanks, I added this to mm.git's mm-new branch.


As requested, I dropped Michal's "mm/hugetlb: init tails before
init_migratetype" from the mm-hotfixes-unstable branch.  Michal, can
you please review and perhaps test [01/19] "mm/hugetlb: fix boot panic
with CONFIG_DEBUG_VM and HVO bootmem pages"
(https://lore.kernel.org/20260612035903.2468601-2-songmuchun@xxxxxxxxxxxxx)?
Thanks.


I added cc:stable to [01/19], as CONFIG_DEBUG_VM is not uncommon.


I added this series as-sent.  This means that the four cc:stable
patches won't be offered to -stable maintainers for 2+ months.  If you
feel that some/all of them should be upstreamed earlier than this,
please let me know and I'll make the necessary reorganizations.


And thanks for checking the Sashiko report.  Dang thing ;)