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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <45434FC3-455E-4CE8-9F43-F398D5EC73A9@linux.dev>
Date: Thu, 22 Jan 2026 19:42:47 +0800
From: Muchun Song <muchun.song@...ux.dev>
To: Kiryl Shutsemau <kas@...nel.org>
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 Jan 22, 2026, at 19:33, Muchun Song <muchun.song@...ux.dev> wrote:
> 
> 
> 
>> On Jan 22, 2026, at 19:28, Kiryl Shutsemau <kas@...nel.org> wrote:
>> 
>> 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.
> 
> Why would you think it would be discovered early? If the alignment of struct page
> can only meet the needs of 4M pages (i.e., the largest pages that buddy can
> allocate), how can you be sure that there will be a similar path using CMA
> early on if the system allocates through CMA in the future (after all, CMA
> is used much less than buddy)?

Suppose we are more aggressive. If the alignment requirement of struct page
cannot meet the needs of 2GB pages (which is an uncommon memory allocation
requirement), then users might not care about such a warning message after
the system boots. And if there is no allocation of pages greater than or
equal to 2GB for a period of time in the future, the system will have no
problems. But once some path allocates pages greater than or equal to 2GB,
the system will go into chaos. And by that time, the system log may no
longer have this warning message. Is that not the case?

> 
>> 
>> -- 
>> Kiryl Shutsemau / Kirill A. Shutemov