linux-kernel - Re: [PATCHv6 06/17] LoongArch/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: <460457b0-64c5-48a2-a5e4-d88ecc222884@kernel.org>
Date: Thu, 5 Feb 2026 14:52:27 +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 06/17] LoongArch/mm: Align vmemmap to maximal folio size

On 2/5/26 14:43, Kiryl Shutsemau wrote:
> On Thu, Feb 05, 2026 at 01:56:36PM +0100, David Hildenbrand (Arm) wrote:
>> On 2/4/26 17:56, David Hildenbrand (arm) wrote:
>>>
>>>
>>> Same comment, the "MAX_FOLIO_NR_PAGES * sizeof(struct page)" is just
>>> black magic here
>>> and the description of the situation is wrong.
>>>
>>> Maybe you want to pull the magic "MAX_FOLIO_NR_PAGES * sizeof(struct
>>> page)" into the core and call it
>>>
>>> #define MAX_FOLIO_VMEMMAP_ALIGN    (MAX_FOLIO_NR_PAGES * sizeof(struct
>>> page))
>>>
>>> But then special case it base on (a) HVO being configured in an (b) HVO
>>> being possible
>>>
>>> #ifdef HUGETLB_PAGE_OPTIMIZE_VMEMMAP && is_power_of_2(sizeof(struct page)
>>> /* A very helpful comment explaining the situation. */
>>> #define MAX_FOLIO_VMEMMAP_ALIGN    (MAX_FOLIO_NR_PAGES * sizeof(struct
>>> page))
>>> #else
>>> #define MAX_FOLIO_VMEMMAP_ALIGN    0
>>> #endif
>>>
>>> Something like that.
>>>
>>
>> Thinking about this ...
>>
>> the vmemmap start is always struct-page-aligned. Otherwise we'd be in
>> trouble already.
>>
>> Isn't it then sufficient to just align the start to MAX_FOLIO_NR_PAGES?
>>
>> Let's assume sizeof(struct page) == 64 and MAX_FOLIO_NR_PAGES = 512 for
>> simplicity.
>>
>> vmemmap start would be multiples of 512 (0x0010000000).
>>
>> 512, 1024, 1536, 2048 ...
>>
>> Assume we have an 256-pages folio at 1536+256 = 0x111000000
> 
> s/0x/0b/, but okay.

:)

> 
>> Assume we have the last page of that folio (0x011111111111), we would just
>> get to the start of that folio by AND-ing with ~(256-1).
>>
>> Which case am I ignoring?
> 
> IIUC, you are ignoring the actual size of struct page. It is not 1 byte :P

I thought it wouldn't matter but, yeah, that's it.

"Align the vmemmap to the maximum folio metadata size" it is.

Then you can explain the situation also alongside 
MAX_FOLIO_VMEMMAP_ALIGN, and that we expect this to be a power of 2.

-- 
Cheers,

David