linux-kernel - Re: [PATCHv4 07/14] mm/sparse: Check memmap alignment for compound_info_has

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: <aXIJY5irR0obgdQe@thinkstation>
Date: Thu, 22 Jan 2026 11:28:06 +0000
From: Kiryl Shutsemau <kas@...nel.org>
To: Muchun Song <muchun.song@...ux.dev>
Cc: Andrew Morton <akpm@...ux-foundation.org>, 
	David Hildenbrand <david@...nel.org>, 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>, kernel-team@...a.com, 
	linux-mm@...ck.org, linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCHv4 07/14] mm/sparse: Check memmap alignment for
 compound_info_has_mask()

On Thu, Jan 22, 2026 at 11:10:26AM +0800, Muchun Song wrote:
> 
> 
> > On Jan 22, 2026, at 00:22, Kiryl Shutsemau <kas@...nel.org> wrote:
> > 
> > If page->compound_info encodes a mask, it is expected that memmap to be
> > naturally aligned to the maximum folio size.
> > 
> > Add a warning if it is not.
> > 
> > A warning is sufficient as MAX_FOLIO_ORDER is very rarely used, so the
> > kernel is still likely to be functional if this strict check fails.
> > 
> > Signed-off-by: Kiryl Shutsemau <kas@...nel.org>
> > ---
> > include/linux/mmzone.h | 1 +
> > mm/sparse.c            | 5 +++++
> > 2 files changed, 6 insertions(+)
> > 
> > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > index 390ce11b3765..7e4f69b9d760 100644
> > --- a/include/linux/mmzone.h
> > +++ b/include/linux/mmzone.h
> > @@ -91,6 +91,7 @@
> > #endif
> > 
> > #define MAX_FOLIO_NR_PAGES (1UL << MAX_FOLIO_ORDER)
> > +#define MAX_FOLIO_SIZE (PAGE_SIZE << MAX_FOLIO_ORDER)
> > 
> > enum migratetype {
> > MIGRATE_UNMOVABLE,
> > diff --git a/mm/sparse.c b/mm/sparse.c
> > index 17c50a6415c2..5f41a3edcc24 100644
> > --- a/mm/sparse.c
> > +++ b/mm/sparse.c
> > @@ -600,6 +600,11 @@ void __init sparse_init(void)
> > 	BUILD_BUG_ON(!is_power_of_2(sizeof(struct mem_section)));
> > 	memblocks_present();
> > 
> > + 	if (compound_info_has_mask()) {
> > + 		WARN_ON(!IS_ALIGNED((unsigned long)pfn_to_page(0),
> > +    			MAX_FOLIO_SIZE / sizeof(struct page)));
> 
> I still have concerns about this. If certain architectures or configurations,
> especially when KASLR is enabled, do not meet the requirements during the
> boot stage, only specific folios larger than a certain size might end up with
> incorrect struct page entries as the system runs. How can we detect issues
> arising from either updating the struct page or making incorrect logical
> judgments based on information retrieved from the struct page?
> 
> After all, when we see this warning, we don't know when or if a problem will
> occur in the future. It's like a time bomb in the system, isn't it? Therefore,
> I would like to add a warning check to the memory allocation place, for
> example: 
> 
>   WARN_ON(!IS_ALIGNED((unsigned long)&folio->page, folio_size / sizeof(struct page)));

I don't think it is needed. Any compound page usage would trigger the
problem. It should happen pretty early.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov