On Thu, Sep 17, 2026 at 10:41 PM Wen Jiang <[email protected]> wrote: > > On Thu, 17 Sept 2026 at 22:00, Christophe Leroy (CS GROUP) > <[email protected]> wrote: > > > > > > > > Le 17/09/2026 à 07:29, Wen Jiang a écrit : > > > From: Wen Jiang <[email protected]> > > > > > > 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. WARN_ON_ONCE() makes that > > > explicit rather than silently doing nothing. > > > > > > Signed-off-by: Wen Jiang <[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 cdd68ed3ae1a9..349ced999f959 100644 > > > --- a/include/linux/pgtable.h > > > +++ b/include/linux/pgtable.h > > > @@ -2134,6 +2134,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) > > > +{ > > > + WARN_ON_ONCE(1); > > > > BUILD_BUG_ON() would be better here. > > > > It should be possible because fallback arch_vmap_pte_range_map_size() > > will constant-fold PAGE_SIZE so pte_set_huge() will never be called. > > > > Agreed. These fallbacks exist only to keep the build working on > architectures with PTE-level block mappings and should never actually > be reached, so BUILD_BUG_ON() is right. I'll make that change in v9. >
I am not quite sure. It won't be called at runtime because `vmap size`/`unmap size` return `PAGE_SIZE`, so the code won't reach this branch. But it will still be built. So, would a `BUILD_BUG_ON()` trigger a build failure here? Best Regards Barry
