linux-kernel - Re: [PATCHv2 02/14] mm/sparse: Check memmap alignment

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: <bed4daf8-9a35-4a88-bb35-2f178d8afa73@kernel.org>
Date: Fri, 9 Jan 2026 16:24:37 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Kiryl Shutsemau <kas@...nel.org>
Cc: Matthew Wilcox <willy@...radead.org>, Muchun Song
 <muchun.song@...ux.dev>, 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>,
 kernel-team@...a.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 linux-doc@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>,
 Usama Arif <usamaarif642@...il.com>, Frank van der Linden <fvdl@...gle.com>
Subject: Re: [PATCHv2 02/14] mm/sparse: Check memmap alignment

>> For quite some time there will be a magical config option that will switch
>> between both layouts. I'd assume that things will get more complicated if we
>> suddenly have a "compound_head/folio" pointer and a "compound_info" pointer
>> at the same time.
>>
>> But it's really Willy who has the concept in mind as he is very likely right
>> now busy writing some of that code.
>>
>> I'm just the messenger.
>>
>> :)
>>
>> [I would hope that Willy could share his thoughts]
> 
> If you or Willy think that this patch will impede memdesc progress, I am
> okay not pushing this patchset upstream.

I pinged Willy.

> 
> I was really excited when I found this trick to get rid of fake heads.
> But ultimately, it is a clean up. I failed to find a performance win I
> hoped for.

I think it's quite nice as a cleanup, and if we wouldn't have memdescs 
on the horizon that essentially change the code completely in another 
direction (having all pages point to a struct folio, not just the tail 
pages), I wouldn't be bringing this up :)

> 
> Also, I try to understand what 32-byte layout means for fake heads.
> _refcount in struct page is going to 0 and refcounting happens on folios.

Yes, for folios.

> So I wounder if we can all pages identical (no tail pages per se) and
> avoid fake heads this way?

That's the ultimate goal, yes. Essentially, all pages will point to the
memdesc, and there will not be a reason to check for head/fake-head etc.

I think initially, the compound-page concept might
still co-exist for some memdescs that we won't initially allocate 
separately.
But I don't know the details of that.

I know that the transition phase is tricky :)

Regarding reference and folios: yes exactly. When trying to get a 
reference, we'll spot in the memdesc field that this is a folio and try 
on the folio instead.

In the future, most pages will either be permanently frozen and not have 
a refcount (e.g., struct ptdesc), or have a refcount in their memdesc. 
In the transition, the location of the refcount depends on memdesc type 
(in memdesc vs. in page).

-- 
Cheers

David