Re: [PATCH] riscv/mm: use physical alignment for vmemmap_start_pfn

[Andrew Morton <akpm@linux-foundation.org>]

On Thu, 16 Jul 2026 11:53:25 +0000 Jiakai Xu <xujiakai2025@iscas.ac.cn> wrote:

> RISC-V computes vmemmap_start_pfn by rounding phys_ram_base down to
> VMEMMAP_ADDR_ALIGN. That alignment must therefore be expressed in the
> physical-address domain.
> 
> Commit 476849b0fba4 ("riscv/mm: align vmemmap to maximal folio size")
> attempted to account for the maximal folio alignment by feeding
> MAX_FOLIO_VMEMMAP_ALIGN directly into VMEMMAP_ADDR_ALIGN. However,
> MAX_FOLIO_VMEMMAP_ALIGN is measured in bytes of struct page storage,
> whereas VMEMMAP_ADDR_ALIGN is used to align a physical address.
> 
> The mask-based compound_info encoding requires pfn_to_page(0) to be
> naturally aligned to MAX_FOLIO_VMEMMAP_ALIGN. Commit 9f94db4c7eaa
> ("mm/sparse: check memmap alignment for compound_info_has_mask()")
> added a check for that requirement and exposed the unit mismatch on
> systems such as QEMU virt, where the DRAM base is not aligned to
> MAX_FOLIO_NR_PAGES * PAGE_SIZE.
> 
> Convert MAX_FOLIO_VMEMMAP_ALIGN to the equivalent physical alignment
> before using it in VMEMMAP_ADDR_ALIGN. This keeps the existing
> round_down() logic while making the resulting vmemmap base satisfy the
> mask-alignment requirement.

Thanks.

> Fixes: 476849b0fba4 ("riscv/mm: align vmemmap to maximal folio size")

That's in 7.1, so I'll add a cc:stable to help ensure this gets
backported.

The changelog doesn't tell people *why* we're proposing a backport - to
understand that we should tell them how the bug affects users.  So I'll
paste your following boot-time warning messages into the changelog.

> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -63,7 +63,8 @@ EXPORT_SYMBOL(phys_ram_base);
>  
>  #ifdef CONFIG_SPARSEMEM_VMEMMAP
>  #define VMEMMAP_ADDR_ALIGN	max(1ULL << SECTION_SIZE_BITS, \
> -				    MAX_FOLIO_VMEMMAP_ALIGN)
> +				    PFN_PHYS(MAX_FOLIO_VMEMMAP_ALIGN / \
> +					     sizeof(struct page)))
>  
>  unsigned long vmemmap_start_pfn __ro_after_init;
>  EXPORT_SYMBOL(vmemmap_start_pfn);

I'll queue this as a backportable hotfix and shall await reviewer input
(please).