linux-kernel - Re: [PATCHv6 05/17] riscv/mm: Align vmemmap to maximal folio size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1b80b189-b549-40ba-800c-8037ce12b081@kernel.org>
Date: Wed, 4 Feb 2026 17:50:23 +0100
From: "David Hildenbrand (arm)" <david@...nel.org>
To: Kiryl Shutsemau <kas@...nel.org>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Muchun Song <muchun.song@...ux.dev>, Matthew Wilcox <willy@...radead.org>,
 Usama Arif <usamaarif642@...il.com>, Frank van der Linden <fvdl@...gle.com>
Cc: Oscar Salvador <osalvador@...e.de>, Mike Rapoport <rppt@...nel.org>,
 Vlastimil Babka <vbabka@...e.cz>,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Zi Yan <ziy@...dia.com>,
 Baoquan He <bhe@...hat.com>, Michal Hocko <mhocko@...e.com>,
 Johannes Weiner <hannes@...xchg.org>, Jonathan Corbet <corbet@....net>,
 Huacai Chen <chenhuacai@...nel.org>, WANG Xuerui <kernel@...0n.name>,
 Palmer Dabbelt <palmer@...belt.com>, Paul Walmsley
 <paul.walmsley@...ive.com>, Albert Ou <aou@...s.berkeley.edu>,
 Alexandre Ghiti <alex@...ti.fr>, kernel-team@...a.com, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
 loongarch@...ts.linux.dev, linux-riscv@...ts.infradead.org
Subject: Re: [PATCHv6 05/17] riscv/mm: Align vmemmap to maximal folio size

On 2/2/26 16:56, Kiryl Shutsemau wrote:
> The upcoming change to the HugeTLB vmemmap optimization (HVO) requires
> struct pages of the head page to be naturally aligned with regard to the
> folio size.
> 
> Align vmemmap to MAX_FOLIO_NR_PAGES.

I think neither that statement nor the one in the patch description is 
correct?

"MAX_FOLIO_NR_PAGES * sizeof(struct page)" is neither the maximum folio 
size nor MAX_FOLIO_NR_PAGES.

It's the size of the memmap that a large folio could span at maximum.


Assuming we have a 16 GiB folio, the calculation would give us

	4194304 * sizeof(struct page)

Which could be something like (assuming 80 bytes)

	335544320

-> not even a power of 2, weird? (for HVO you wouldn't care as HVO would 
be disabled, but that aliment is super weird?)


Assuming 64 bytes, it would be a power of two (as 64 is a power of two).

	268435456 (1<< 28)


Which makes me wonder whether there is a way to avoid sizeof(struct 
page) here completely.

Or limit the alignment to the case where HVO is actually active and 
sizeof(struct page) makes any sense?


> 
> Signed-off-by: Kiryl Shutsemau <kas@...nel.org>
> ---
>   arch/riscv/mm/init.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 21d534824624..c555b9a4fdce 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -63,7 +63,8 @@ phys_addr_t phys_ram_base __ro_after_init;
>   EXPORT_SYMBOL(phys_ram_base);
>   
>   #ifdef CONFIG_SPARSEMEM_VMEMMAP
> -#define VMEMMAP_ADDR_ALIGN	(1ULL << SECTION_SIZE_BITS)
> +#define VMEMMAP_ADDR_ALIGN	max(1ULL << SECTION_SIZE_BITS, \
> +				    MAX_FOLIO_NR_PAGES * sizeof(struct page))
>   
>   unsigned long vmemmap_start_pfn __ro_after_init;
>   EXPORT_SYMBOL(vmemmap_start_pfn);


-- 
Cheers,

David