mm/sparse-vmemmap: drop VMEMMAP_POPULATE_DAX

Patch series "mm: Unify device DAX and HugeTLB vmemmap population paths",
v4.

This series is split out from the earlier, larger series "mm: Generalize
HVO for HugeTLB and device DAX" [2].  While the parent series generalizes
vmemmap optimization across HugeTLB and device DAX, this subset addresses
a single, self-contained step: unifying their vmemmap population paths.

After the preceding Device DAX conversion, both HugeTLB and Device DAX
describe optimized vmemmap mappings through memory-section metadata and
use per-zone shared tail vmemmap pages.  The generic code, however, still
carries a Device DAX-specific population flag and compound-page population
path, along with arguments and helpers needed only by that path.

This series first removes VMEMMAP_POPULATE_DAX and moves selection and
reference handling for the shared tail page into the common vmemmap
population path.  It then removes the generic Device DAX-specific
compound-page population path and routes section vmemmap population
through vmemmap_populate().  The powerpc radix path continues to use its
architecture-specific compound-page population implementation for
optimizable sections.

The remaining patches remove the unused ptpfn argument, open-code
vmemmap_populate_address() now that no caller needs its returned PTE, and
add a warning for inconsistent zone initialization of shared tail vmemmap
pages.

This is the fourth smaller step toward the broader HVO generalization. 
After this series, HugeTLB and Device DAX use the same population model
instead of parallel generic paths, while powerpc keeps its
architecture-specific implementation.


This patch (of 6):

VMEMMAP_POPULATE_DAX currently distinguishes DAX vmemmap population in two
places: it keeps allocations on the normal path and takes a reference when
a backing page is supplied for reuse.

After Device DAX switched to the common per-zone shared tail page, both
conditions can be determined locally.  DAX supplies ptpfn for every shared
tail mapping and requests an allocation only for compound head mappings,
whose PFNs are not optimizable.  Therefore, vmemmap_optimizable_pfn()
alone selects the correct allocation path.

When ptpfn is supplied, the caller is reusing an existing backing page. 
Once the slab allocator is available, take a reference for each reused
mapping to balance the release performed by vmemmap_free().  Although the
buddy allocator is available before slab, no vmemmap population occurs in
that interval.  Earlier mappings are backed by memblock/reserved memory
and do not need page reference accounting.

Remove VMEMMAP_POPULATE_DAX and the flags argument from the vmemmap
population helpers.

Link: https://lore.kernel.org/20261010075755.83339-1-songmuchun@bytedance.com
Link: https://lore.kernel.org/20261010075755.83339-2-songmuchun@bytedance.com
Link: https://lore.kernel.org/20260930140627.57431-1-songmuchun@bytedance.com/ [1]
Link: https://lore.kernel.org/20260513130542.35604-1-songmuchun@bytedance.com/ [2]
Signed-off-by: Muchun Song <muchun.song@linux.dev>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Lance Yang <lance.yang@linux.dev>
Acked-by: Qi Zheng <qi.zheng@linux.dev>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Christophe Leroy <chleroy@kernel.org>
Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Michal Hocko <mhocko@suse.com>

0 files changed, 0 insertions, 0 deletions