Re: [PATCH v11 05/10] arm64/vmalloc: allow arch_vmap_pte_range_map_size() to batch multiple CONT_PTE

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] arm64/vmalloc: physical block overrun in arch_vmap_pte_range_map_size()
--

commit 21610101d177ce2dfc10c0e91b5ac55eb277a5f9
Author: Barry Song (Xiaomi) <baohua@kernel.org>

arm64/vmalloc: allow arch_vmap_pte_range_map_size() to batch multiple CONT_PTE

This commit updates arch_vmap_pte_range_map_size() to return the largest
CONT_PTE_SIZE-aligned size that fits within the remaining range and the
caller's max_page_shift, allowing vmap_pte_set_huge() to install multiple
CONT_PTE blocks in a single call.

> diff --git a/arch/arm64/include/asm/vmalloc.h b/arch/arm64/include/asm/vmalloc.h
> index 4ec1acd3c1b34..c29704a19e276 100644
> --- a/arch/arm64/include/asm/vmalloc.h
> +++ b/arch/arm64/include/asm/vmalloc.h
> @@ -23,10 +23,12 @@ static inline unsigned long arch_vmap_pte_range_map_size(unsigned long addr,
>  						unsigned long end, u64 pfn,
>  						unsigned int max_page_shift)
>  {
> +	unsigned long size;
> +
>  	/*
> -	 * If the block is at least CONT_PTE_SIZE in size, and is naturally
> -	 * aligned in both virtual and physical space, then we can pte-map the
> -	 * block using the PTE_CONT bit for more efficient use of the TLB.
> +	 * If the range is at least CONT_PTE_SIZE and naturally aligned in both
> +	 * virtual and physical space, return the largest CONT_PTE-aligned size
> +	 * that fits, for more efficient use of the TLB.
>  	 */
>  	if (max_page_shift < CONT_PTE_SHIFT)
>  		return PAGE_SIZE;
> @@ -40,7 +42,9 @@ static inline unsigned long arch_vmap_pte_range_map_size(unsigned long addr,
>  	if (!IS_ALIGNED(PFN_PHYS(pfn), CONT_PTE_SIZE))
>  		return PAGE_SIZE;
>  
> -	return CONT_PTE_SIZE;
> +	size = min(end - addr, 1UL << max_page_shift);
> +	size = round_down(size, CONT_PTE_SIZE);
> +	return size;

[Severity: Critical]
As reported by David Carlier on v7 [1], can arch_vmap_pte_range_map_size()
overrun the current physically contiguous block when a PMD boundary splits a
coalesced batch?

In the batched vmap() path introduced later in this series:

  vmap()
    -> vmap_pages_range()
      -> vmap_pages_range_noflush()
        -> vmap_pages_range_batched()
          -> vmap_pages_range_noflush_walk()

vmap_pages_range_batched() coalesces consecutive blocks that share the same
mapping shift (where shift > CONT_PTE_SHIFT) into a single walk over
[batch_start, batch_end). Within that coalesced range, pages[] is only
physically contiguous within each naturally aligned (1UL << max_page_shift)
block; separate blocks in the same batch are not physically contiguous with
each other.

If [batch_start, batch_end) is only aligned to CONT_PTE_SIZE and crosses a
PMD boundary mid-block, vmap_pages_pmd_range() splits the walk at
pmd_addr_end(addr, end). The first PMD maps the initial CONT_PTE_SIZE-aligned
portion of the block, advancing *nr into the middle of that physical block.

At the start of the next PMD, addr and PFN_PHYS(pfn) are still aligned to
CONT_PTE_SIZE, while end - addr includes the subsequent block(s) in the
batch. Because arch_vmap_pte_range_map_size() only checks
IS_ALIGNED(PFN_PHYS(pfn), CONT_PTE_SIZE) and does not bound size to the
remaining bytes in the current (1UL << max_page_shift) physical block, it can
return up to (1UL << max_page_shift) starting from a mid-block PFN.

Won't vmap_pte_set_huge() then map physical pages past the end of that block
while vmap_pages_pte_range() advances *nr past the start of the next block in
pages[], leaving the tail of pages[] unmapped?

[1] https://lore.kernel.org/r/20260721181729.305137-1-devnexen@gmail.com

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103101658.766905-1-jiangwenxiaomi@gmail.com?part=5