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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <f47be155-8e3c-4bd2-b312-0e7c57620797@kernel.org>
Date: Thu, 5 Feb 2026 14:54:51 +0100
From: "David Hildenbrand (Arm)" <david@...nel.org>
To: Kiryl Shutsemau <kas@...nel.org>
Cc: 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>,
 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/5/26 14:50, Kiryl Shutsemau wrote:
> On Wed, Feb 04, 2026 at 05:50:23PM +0100, David Hildenbrand (arm) wrote:
>> 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.
> 
> I don't think we can. See the other thread.

Agreed. You could only go for something larger (like PAGE_SIZE).

> 
> What about using roundup_pow_of_two(sizeof(struct page)) here.

Better I think.

> 
>> Or limit the alignment to the case where HVO is actually active and
>> sizeof(struct page) makes any sense?
> 
> The annoying part of HVO is that it is unknown at compile-time if it
> will be used. You can compile kernel with HVO that will no be activated
> due to non-power-of-2 sizeof(struct page) because of a debug config option.
Ah, and now I remember that sizeof cannot be used in macros, damnit.

-- 
Cheers,

David