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

[Christophe Leroy (CS GROUP)]

Le 17/09/2026 à 23:44, Barry Song a écrit :
> On Thu, Sep 17, 2026 at 10:41 PM Wen Jiang <jiangwenxiaomi at gmail.com> wrote:
>>
>> On Thu, 17 Sept 2026 at 22:00, Christophe Leroy (CS GROUP)
>> <chleroy at kernel.org> wrote:
>>>
>>>
>>>
>>> Le 17/09/2026 à 07:29, Wen Jiang a écrit :
>>>> From: Wen Jiang <jiangwen6 at xiaomi.com>
>>>>
>>>> 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 at xiaomi.com>
>>>> ---
>>>>    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.

The fallbacks are defined as:

#ifndef arch_vmap_pte_range_map_size
static inline unsigned long arch_vmap_pte_range_map_size(unsigned long 
addr, unsigned long end,
							 u64 pfn, unsigned int max_page_shift)
{
	return PAGE_SIZE;
}
#endif

#ifndef arch_vmap_pte_range_unmap_size
static inline unsigned long arch_vmap_pte_range_unmap_size(unsigned long 
addr,
							   pte_t *ptep)
{
	return PAGE_SIZE;
}
#endif

Therefore in:

                 size = arch_vmap_pte_range_unmap_size(addr, pte);
                 if (size != PAGE_SIZE) {

GCC knows 'size' is const and its value is PAGE_SIZE, so it won't emit 
the branch at all.

It is call constant folding, some explanation here: 
https://en.wikipedia.org/wiki/Constant_folding

> 
> So, would a `BUILD_BUG_ON()` trigger a build failure here?

It shouldn't, if it does it is a compiled bug or this is because someone 
has redefined arch_vmap_pte_range_map_size() and not pte_set_huge() 
which we'd better know at build time rather than at runtime.


> 
> Best Regards
> Barry
>