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

[Muchun Song]

> On Apr 1, 2026, at 04:04, David Hildenbrand (Arm) <david@xxxxxxxxxx> wrote:
> 
> On 3/31/26 21:55, Andrew Morton wrote:
>> On Tue, 31 Mar 2026 19:30:23 +0800 Muchun Song <songmuchun@xxxxxxxxxxxxx> wrote:
>> 
>>> The comment in mmzone.h states that the alignment requirement
>>> is the minimum of PAGE_SHIFT and PFN_SECTION_SHIFT. However, the
>>> pointer arithmetic (mem_map - section_nr_to_pfn()) results in
>>> a byte offset scaled by sizeof(struct page). Thus, the actual
>>> alignment provided by the second term is PFN_SECTION_SHIFT +
>>> __ffs(sizeof(struct page)).
>>> 
>>> Update the compile-time check and the mmzone.h comment to
>>> accurately reflect this mathematically guaranteed alignment by
>>> taking the minimum of PAGE_SHIFT and PFN_SECTION_SHIFT +
>>> __ffs(sizeof(struct page)). This avoids the issue of the check
>>> being overly restrictive on architectures like powerpc where
>>> PFN_SECTION_SHIFT alone is very small (e.g., 6).
>>> 
>>> Also, remove the exhaustive per-architecture bit-width list from the
>>> comment; such details risk falling out of date over time and may
>>> inadvertently be left un-updated, while the existing BUILD_BUG_ON
>>> provides sufficient compile-time verification of the constraint.
>>> 
>>> No runtime impact so far: SECTION_MAP_LAST_BIT happens to fit within
>>> the smaller limit on all existing architectures.
>> 
>> Thanks.  So this can fix the build on some arch/kconfig combinations?
>> 
>> Do you think we should fix older kernels?
>> 
>>> Fixes: def9b71ee651 ("include/linux/mmzone.h: fix explanation of lower bits in the SPARSEMEM mem_map pointer")
>> 
>> Eight years ago so I'm going with "no".
> 
> IIUC, there is nothing broken. Could only be revealed by some new
> architecture.

Or increasing SECTION_MAP_LAST_BIT for powerpc in the future.

> 
> So no stable :)

Absolutely right.

Thanks.

> 
> -- 
> Cheers,
> 
> David