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] [day] [month] [year] [list]

Message-ID: <51fe7876-c24b-48b9-a038-6cd850ebe512@kernel.org>
Date: Tue, 13 Jan 2026 11:24:26 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Matthew Wilcox <willy@...radead.org>
Cc: Kiryl Shutsemau <kas@...nel.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

>> When the program was called "2025" I considered it very ambitious :) Now I
>> consider it ambitious. I think Willy already shared early versions of the
>> "struct slab" split and the "struct ptdesc" split recently on the list.
> 
> ptdesc, yes.  Slab is still in progress.

Ah, I could have sworn you sent something out, but maybe these were 
preparations only. :)

> 
>> 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.
> 
> What I'm hoping to get to is a point where calling compound_head() on
> a page which is part of a folio is a BUG.  You should only be calling
> page_folio() on a page which is part of a folio -- because there's nothing
> useful to find in the head page.  So compound_head (or compound_info) can
> share space with page->memdesc.  For now I've actually put page->memdesc
> adjacent to page->compound_head, for no reason that I can recall.
> 
> I had thought that calling page_folio() on a page that's not part of
> a folio would also be a BUG(), but now I think it's better to quietly
> return NULL.  That's based on my experience working with slab and ptdesc.

So once that is in, even if we only allocate "struct folio" separately, 
the whole fake-head stuff can go away either way, as it is 
hugetlb->folio material only.

Which leaves the question whether we should consider Kiryl's patch set 
in the meantime here as something to merge.

Willy, what is the rough timeline until we can expect to see at least 
"struct folio" get allocated separately, and would this patch set here 
get in the way of doing so, or doesn't it really matter?

-- 
Cheers

David