linux-kernel - Re: [PATCHv5 09/17] 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: <5AFAE2FC-7274-4A23-AE92-797D5B69AA8B@nvidia.com>
Date: Wed, 28 Jan 2026 22:29:38 -0500
From: Zi Yan <ziy@...dia.com>
To: Muchun Song <muchun.song@...ux.dev>
Cc: Kiryl Shutsemau <kas@...nel.org>,
 Andrew Morton <akpm@...ux-foundation.org>,
 David Hildenbrand <david@...hat.com>, 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>, Baoquan He <bhe@...hat.com>,
 Michal Hocko <mhocko@...e.com>, Johannes Weiner <hannes@...xchg.org>,
 Jonathan Corbet <corbet@....net>, Huacai Chen <chenhuacai@...nel.org>,
 WANG Xuerui <kernel@...0n.name>, Palmer Dabbelt <palmer@...belt.com>,
 Paul Walmsley <paul.walmsley@...ive.com>, Albert Ou <aou@...s.berkeley.edu>,
 Alexandre Ghiti <alex@...ti.fr>, kernel-team@...a.com, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
 loongarch@...ts.linux.dev, linux-riscv@...ts.infradead.org
Subject: Re: [PATCHv5 09/17] mm/sparse: Check memmap alignment for
 compound_info_has_mask()

On 28 Jan 2026, at 22:23, Muchun Song wrote:

>> On Jan 29, 2026, at 11:10, Zi Yan <ziy@...dia.com> wrote:
>>
>> On 28 Jan 2026, at 22:00, Muchun Song wrote:
>>
>>>> On Jan 28, 2026, at 21:54, Kiryl Shutsemau <kas@...nel.org> wrote:
>>>>
>>>> If page->compound_info encodes a mask, it is expected that vmemmap to be
>>>> naturally aligned to the maximum folio size.
>>>>
>>>> Trigger a BUG() for CONFIG_DEBUG_VM=y or WARN() otherwise.
>>>>
>>>> Signed-off-by: Kiryl Shutsemau <kas@...nel.org>
>>>> Acked-by: Zi Yan <ziy@...dia.com>
>>>> ---
>>>> mm/sparse.c | 13 +++++++++++++
>>>> 1 file changed, 13 insertions(+)
>>>>
>>>> diff --git a/mm/sparse.c b/mm/sparse.c
>>>> index b5b2b6f7041b..9c0f4015778c 100644
>>>> --- a/mm/sparse.c
>>>> +++ b/mm/sparse.c
>>>> @@ -600,6 +600,19 @@ void __init sparse_init(void)
>>>> BUILD_BUG_ON(!is_power_of_2(sizeof(struct mem_section)));
>>>> memblocks_present();
>>>>
>>>> +  if (compound_info_has_mask()) {
>>>> +  	unsigned long alignment;
>>>> +  	bool aligned;
>>>> +
>>>> +  	alignment = MAX_FOLIO_NR_PAGES * sizeof(struct page);
>>>> +  	aligned = IS_ALIGNED((unsigned long) pfn_to_page(0), alignment);
>>>> +
>>>> +  	if (IS_ENABLED(CONFIG_DEBUG_VM))
>>>> +  		BUG_ON(!aligned);
>>>> +  	else
>>>> +  		WARN_ON(!aligned);
>>>
>>> Since you’ve fixed all the problematic architectures, I don’t believe
>>> we’ll ever hit the WARN or BUG here anymore.
>>>
>>> I think we can now simplify the code further and just use VM_BUG_ON:
>>> if any architecture changes in the future, the misalignment will be
>>> caught during testing, so we won’t need to worry about it at run-time.
>>>
>>
>> VM_WARN_ON should be sufficient, since bots should report warnings
>> from any patch/change.
>
> I’m not sure a WARN will get developers’ attention, since the message
> is unlikely to have any visible consequences and only fires on
> allocations with a special order.

If a developer misses the WARN and the patch gets into linux-mm or linux-next,
kernel test robot runs selftests on the kernel and reports any warnings
to the mailing list. Do we have any related test in selftests/mm? That should
help us catch anything if a developer does not catch it.

Best Regards,
Yan, Zi