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

On Thu, 24 Sept 2026 at 05:38, Barry Song [off-list ref] wrote:

On Wed, Sep 23, 2026 at 2:28 PM Wen Jiang [off-list ref] wrote:

quoted

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:

Since this is a `BUILD_BUG`, can the compiler simply eliminate the call?
I guess the build would still pass even without the fallbacks, so this is
more of a build-time check than something needed to keep the build passing?

Am I missing something?

Hi Barry,

The generic fallbacks are actually needed to keep the build passing.
Without them, x86 defconfig fails with "implicit declaration of
function 'pte_set_huge'" — the compiler requires a declaration at the
call site before dead code elimination can kick in. So "keep the build
working" in the changelog is accurate.

Thanks,
Wen

quoted

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. BUILD_BUG() makes that
explicit rather than silently doing nothing.

Signed-off-by: Wen Jiang <redacted>

Nice to see that `#ifdef CONFIG_HUGETLB_PAGE` and
`#include <linux/hugetlb.h>` are no longer needed in `vmalloc`.

Nothing concerns me except for the changelog issue mentioned above.
Please double-check whether the changelog needs to be corrected.

Reviewed-by: Barry Song <baohua@kernel.org>