Re: [PATCH] mm/sparse: fix BUILD_BUG_ON check for section map alignment

Muchun Song
2026-04-01T07:24:50Z

> On Apr 1, 2026, at 15:08, David Hildenbrand (Arm) <david@kernel.org> wrote:
>
> On 4/1/26 06:01, Muchun Song wrote:
>>
>>
>>> On Apr 1, 2026, at 10:57, Muchun Song <muchun.song@linux.dev> wrote:
>>>
>>>
>>>
>>>>
>>>>
>>>> If that would trigger, wouldn't the memmap of a memory section be
>>>> smaller than a single page?
>>>
>>> I don't think a memory section can be smaller than a page, because
>>> PFN_SECTION_SHIFT is defined as follows:
>>>
>>> #define PFN_SECTION_SHIFT (SECTION_SIZE_BITS - PAGE_SHIFT)
>>>
>>> Therefore, PFN_SECTION_SHIFT must be greater than PAGE_SHIFT. On powerpc,
>>> PFN_SECTION_SHIFT is 6, PAGE_SHIFT is 18 (the worst combination).
>>>
>>> Sorry, but I didn't understand what your concern is. Could you elaborate
>>> a bit more?
>>
>> Sorry, I misread it earlier — I thought it was about the memory
>> section size, but it's actually about the memmap size. Let me respond
>> again to your question. On the powerpc architecture, when PFN_SECTION_SHIFT
>> is 6 and PAGE_SHIFT is 18, it does seem that the memmap of a memory
>> section would be smaller than a single page.
>
> Right, and I am saying we don't care about that and do not support it.
>
> For example, most vmemmap code I am aware of relies on a single section
> covering full pages.
>
> So I don't think this patch here adds any value, except faking that we
> might be supporting something we don't?

Got it.

My original motivation was simply that when I read this part of the code,
the comment felt a bit off to me, so I just fixed it casually. But if it
ends up creating the impression that "we might be supporting something
we don't," as you said, then I'm fine with dropping this patch.

Thanks.

>
> --
> Cheers,
>
> David