Re: [PATCH v8 03/10] mm/vmalloc: use pte_set_huge()/pte_clear_huge() for PTE-level block mappings
From: Christophe Leroy (CS GROUP)
Date: Fri Sep 18 2026 - 02:05:49 EST
Le 17/09/2026 à 23:44, Barry Song a écrit :
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.
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