[PATCHv5 09/17] mm/sparse: Check memmap alignment for compound_info_has_mask()
Zi Yan
ziy at nvidia.com
Thu Jan 29 09:33:57 PST 2026
On 29 Jan 2026, at 2:03, Muchun Song wrote:
>> On Jan 29, 2026, at 11:29, Zi Yan <ziy at nvidia.com> wrote:
>>
>> On 28 Jan 2026, at 22:23, Muchun Song wrote:
>>
>>>> On Jan 29, 2026, at 11:10, Zi Yan <ziy at nvidia.com> wrote:
>>>>
>>>> On 28 Jan 2026, at 22:00, Muchun Song wrote:
>>>>
>>>>>> On Jan 28, 2026, at 21:54, Kiryl Shutsemau <kas at kernel.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 at kernel.org>
>>>>>> Acked-by: Zi Yan <ziy at nvidia.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.
>
> I looked at the selftest and it doesn’t seem to have a test that
> allocates at MAX_FOLIO_ORDER and checks that it works correctly.
OK, we probably need a selftest for it. In terms of using VM_BUG_ON or
VM_WARN_ON, I leave that decision to you and Kiryl.
Thank you for the clarification.
Best Regards,
Yan, Zi
More information about the linux-riscv
mailing list