Re: [PATCHv2 02/14] mm/sparse: Check memmap alignment

[Muchun Song <muchun.song@linux.dev>]

> On Dec 22, 2025, at 22:52, Kiryl Shutsemau <kas@kernel.org> wrote:
> 
> On Mon, Dec 22, 2025 at 03:18:29PM +0100, David Hildenbrand (Red Hat) wrote:
>>> On 12/22/25 15:02, Kiryl Shutsemau wrote:
>>> On Mon, Dec 22, 2025 at 04:34:40PM +0800, Muchun Song wrote:
>>>> 
>>>> 
>>>> On 2025/12/18 23:09, Kiryl Shutsemau wrote:
>>>>> The upcoming changes in compound_head() require 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.
>>>> 
>>>> Different architectures default to 2 MB alignment (mainly to
>>>> enable huge mappings), which only accommodates folios up to
>>>> 128 MB. Yet 1 GB huge pages are still fairly common, so
>>>> validating 16 GB (MAX_FOLIO_SIZE) alignment seems likely to
>>>> miss the most frequent case.
>>> 
>>> I don't follow. 16 GB check is more strict that anything smaller.
>>> How can it miss the most frequent case?
>>> 
>>>> I’m concerned that this might plant a hidden time bomb: it
>>>> could detonate at any moment in later code, silently triggering
>>>> memory corruption or similar failures. Therefore, I don’t
>>>> think a WARNING is a good choice.
>>> 
>>> We can upgrade it BUG_ON(), but I want to understand your logic here
>>> first.
>> 
>> Definitely no BUG_ON(). I would assume this is something we would find early
>> during testing, so even a VM_WARN_ON_ONCE() should be good enough?
>> 
>> This smells like a possible problem, though, as soon as some architecture
>> wants to increase the folio size. What would be the expected step to ensure
>> the alignment is done properly?
> 
> It depends on memory model and whether the arch has KASLR for memmap.

Yes. Theoretically, the most correct approach is
to ensure that the randomly chosen offset at the
KASLR relocation site meets alignment
requirements, and it likely needs to be adapted
for each architecture—sounds rather tedious.

> 
>> But OTOH, as I raised Willy's work will make all of that here obsolete
>> either way, so maybe not worth worrying about that case too much,
> 
> Willy, what is timeline here?
> 
> --
>  Kiryl Shutsemau / Kirill A. Shutemov