On Fri, Oct 02, 2026 at 05:09:40PM +0800, Wen Jiang wrote: > vmap installs PTE-level block mappings by reusing set_huge_pte_at() and > huge_ptep_get_and_clear() under #ifdef CONFIG_HUGETLB_PAGE. This makes > the feature silently unavailable on CONFIG_HUGETLB_PAGE=n kernels and > couples mm/vmalloc.c to HugeTLB internals it does not otherwise need. > > Now that arm64 and powerpc/8xx provide pte_set_huge() and > pte_clear_huge(), add the generic fallbacks next to the existing > pmd/pud_set_huge() family and convert vmap_pte_range() and > vunmap_pte_range() to the new helpers. The CONFIG_HUGETLB_PAGE guards > around the block-mapping paths are dropped, so PTE-level block mappings > now also work on CONFIG_HUGETLB_PAGE=n kernels, and mm/vmalloc.c no > longer includes <linux/hugetlb.h>. > > The fallbacks exist only to keep the build working on architectures > without PTE-level block mapping support. They are unreachable there: > the callers only run when arch_vmap_pte_range_map_size() or > arch_vmap_pte_range_unmap_size() return a size other than PAGE_SIZE, > which requires an arch implementation. BUILD_BUG() makes that > explicit rather than silently doing nothing. > > Signed-off-by: Wen Jiang <[email protected]> > Reviewed-by: Barry Song <[email protected]> > --- > include/linux/pgtable.h | 29 +++++++++++++++++++++++++++++ > mm/vmalloc.c | 19 ++++++------------- > 2 files changed, 35 insertions(+), 13 deletions(-) > > diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h > index 8c093c119e5a8..a7fd51fec8a17 100644 > --- a/include/linux/pgtable.h > +++ b/include/linux/pgtable.h > @@ -2204,6 +2204,35 @@ static inline int pmd_free_pte_page(pmd_t *pmd, > unsigned long addr) > } > #endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */ > > +/* > + * PTE-level block mappings for vmap. > + * > + * pte_set_huge() only has to be implemented by architectures whose > + * arch_vmap_pte_range_map_size() can return a size other than PAGE_SIZE. > + */ > +#ifndef __HAVE_ARCH_PTE_SET_HUGE > +static inline void pte_set_huge(pte_t *ptep, unsigned long addr, > + phys_addr_t phys, pgprot_t prot, > + unsigned long size) > +{ > + BUILD_BUG(); > +} > +#endif > + > +/* > + * Likewise, pte_clear_huge() only has to be implemented by architectures > + * whose arch_vmap_pte_range_unmap_size() can return a size other than > + * PAGE_SIZE. > + */ > +#ifndef __HAVE_ARCH_PTE_CLEAR_HUGE > +static inline pte_t pte_clear_huge(pte_t *ptep, unsigned long addr, > + unsigned long size) > +{ > + BUILD_BUG(); > + return __pte(0); > +} > +#endif > + > #ifndef __HAVE_ARCH_FLUSH_PMD_TLB_RANGE > #ifdef CONFIG_TRANSPARENT_HUGEPAGE > /* > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index bea9f76ed7e74..fb757d95bde25 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -38,7 +38,6 @@ > #include <linux/rbtree_augmented.h> > #include <linux/overflow.h> > #include <linux/pgtable.h> > -#include <linux/hugetlb.h> > #include <linux/sched/mm.h> > #include <asm/tlbflush.h> > #include <asm/shmparam.h> > @@ -100,7 +99,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, > unsigned long end, > pte_t *pte; > u64 pfn; > struct page *page; > - unsigned long size = PAGE_SIZE; > + unsigned long size; > > if (WARN_ON_ONCE(!PAGE_ALIGNED(end - addr))) > return -EINVAL; > @@ -121,17 +120,12 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long > addr, unsigned long end, > BUG(); > } > > -#ifdef CONFIG_HUGETLB_PAGE > size = arch_vmap_pte_range_map_size(addr, end, pfn, > max_page_shift); > if (size != PAGE_SIZE) { > - pte_t entry = pfn_pte(pfn, prot); > - > - entry = arch_make_huge_pte(entry, ilog2(size), 0); > - set_huge_pte_at(&init_mm, addr, pte, entry, size); > + pte_set_huge(pte, addr, PFN_PHYS(pfn), prot, size); > As far as i understand, X86_64 arches do not use this path. This specifically is only for ARM64 or powerpc. pte_set_huge() makes me thinking about huge-page mappings(PMD/PUD/hugetlb). This helper is about mutli page mapping on the PTE level.
Better naming? pte_set_large()? Any thoughts? Other then that: Reviewed-by: Uladzislau Rezki (Sony) <[email protected]> -- Uladzislau Rezki
