Re: [PATCH v8 03/10] mm/vmalloc: use pte_set_huge()/pte_clear_huge() for PTE-level block mappings

[Barry Song]

On Thu, Sep 17, 2026 at 10:41 PM Wen Jiang <jiangwenxiaomi@xxxxxxxxx> wrote:
>
> On Thu, 17 Sept 2026 at 22:00, Christophe Leroy (CS GROUP)
> <chleroy@xxxxxxxxxx> wrote:
> >
> >
> >
> > Le 17/09/2026 à 07:29, Wen Jiang a écrit :
> > > From: Wen Jiang <jiangwen6@xxxxxxxxxx>
> > >
> > > 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 <jiangwen6@xxxxxxxxxx>
> > > ---
> > >   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