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: <aWF3xg-72SV4tmLk@casper.infradead.org>
Date: Fri, 9 Jan 2026 21:48:54 +0000
From: Matthew Wilcox <willy@...radead.org>
To: "David Hildenbrand (Red Hat)" <david@...nel.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

On Thu, Jan 08, 2026 at 12:08:35AM +0100, David Hildenbrand (Red Hat) wrote:
> > > "Then we make page->compound_head point to the dynamically allocated memdesc
> > > rather than the first page. Then we can transition to the above layout. "
> > 
> 
> Sorry for the late reply, it's been a bit crazy over here.
> 
> > I am not sure I understand how it is going to work.
> > 
> 
> I don't recall all the details that Willy shared over the last years while
> working on folios, but I will try to answer as best as I can from the top of
> my head. (there are plenty of resources on the list, on the web, in his
> presentations etc.).
> 
> > 32-byte layout indicates that flags will stay in the statically
> > allocated part, but most (all?) flags are in the head page and we would
> > need a way to redirect from tail to head in the statically allocated
> > pages.
> 
> When working with folios we will never go through the head page flags.
> That's why Willy has incrementally converted most folio code that worked on
> pages to work on folios.

A little more detail here:

 - Zone/Node/Section stay in page->flags and are replicated to
   folio->flags
 - HWPoison stays in page->flags
 - Reserved stays in page->flags
 - AnonExclusive stays in page->flags
 - Writeback/Referenced/Uptodate/Dirty/LRU/Active/Workingset/Owner1/
   Owner2/Reclaim/Swapbacked/Unevictable/Dropbehind/MLocked/Young/Idle
   all exist only in folio->flags
 - Head/Private/Private2 all go away
 - Locked & Waiters are ... complicated.  I'll elaborate if there's
   demand.
 - I haven't put any effort into analyzing the Xen flags.
 - HasHWPoisoned/LargeRmappable/PartiallyMapped all move to folio->flags

> 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.

> 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.