On Fri, 18 Sept 2026 at 07:22, Barry Song <[email protected]> wrote: > > On Thu, Sep 17, 2026 at 1:29 PM Wen Jiang <[email protected]> wrote: > > > > From: Wen Jiang <[email protected]> > > > > vmap installs PTE-level block mappings (PTE_CONT on arm64) by reusing > > set_huge_pte_at() and huge_ptep_get_and_clear(), which are HugeTLB > > helpers gated by 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. > > > > Add pte_set_huge()/pte_clear_huge() to arm64, joining the existing > > pmd_set_huge()/pud_set_huge() family in mm/mmu.c. They build on > > __set_ptes() and __get_and_clear_full_ptes() directly, so they do not > > depend on CONFIG_HUGETLB_PAGE. > > > > There is no caller yet: mm/vmalloc.c is converted later in this series, > > once the generic fallbacks are in place. > > > > Signed-off-by: Wen Jiang <[email protected]> > > I tried to apply the patch to mm-new, but it doesn't apply. > > % git am raw > Applying: arm64/mm: add pte_set_huge() and pte_clear_huge() > error: patch failed: arch/arm64/mm/mmu.c:1872 > error: arch/arm64/mm/mmu.c: patch does not apply > Patch failed at 0001 arm64/mm: add pte_set_huge() and pte_clear_huge() > hint: Use 'git am --show-current-patch=diff' to see the failed patch > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". > > % patch -p1 < raw > patching file 'arch/arm64/include/asm/pgtable.h' > patching file 'arch/arm64/mm/mmu.c' > 1 out of 1 hunks failed--saving rejects to 'arch/arm64/mm/mmu.c.rej' > > > [...] > > > +void pte_set_huge(pte_t *ptep, unsigned long addr, phys_addr_t phys, > > + pgprot_t prot, unsigned long size) > > +{ > > + unsigned long pfn = __phys_to_pfn(phys); > > + pte_t new_pte = pte_mkcont(pfn_pte(pfn, prot)); > > Maybe we can drop the `new_` prefix. >
Will do. > > + unsigned int nr = size >> PAGE_SHIFT; > > + > > + VM_WARN_ON(!IS_ALIGNED(pfn, CONT_PTES)); > > + VM_WARN_ON(!IS_ALIGNED(size, CONT_PTE_SIZE)); > > Do we also need to check that `addr` is aligned? > Yes. arch_vmap_pte_range_map_size() already guarantees all three, since we are already checking two of them here, we should complete the set. I'll add it in v9. Thanks, Wen
