Re: [PATCH] mm/page_alloc: free allocated PFNs if the range does not match

[David Hildenbrand (Arm)]

On 6/30/26 17:06, Zi Yan wrote:
> On Tue Jun 30, 2026 at 9:39 AM EDT, David Hildenbrand (Arm) wrote:
>> On 6/30/26 09:44, Vlastimil Babka (SUSE) wrote:
>>>
>>> So this?
>>> Reported-by: Sashiko <sashiko-bot@xxxxxxxxxx>
>>>
>>>
>>> Hm well, it's a path that warns, can only happen due to a development error?
>>> Not sure we care about stable then. Anyway.
>>>
>>
>> If someone would run into the WARN we would already be in Fixes: territory.
>>
>> it's a path that should never be executed. If it does, the real issue must be fixed.
>>
>> So (a) I don't think this is stable material (b) I am skeptical that this is
>> even a Fixes and (c) I am wondering whether we should touch this *at all*.
>>
>> :)
> 
> I looked at the code again and agree with you that the code is not
> reachable and the fix should not be in the WARN path. Theoretically, if
> order = ilog2(end - start) is smaller than MAX_PAGE_ORDER,
> find_large_buddy() can return an outer_start smaller than start, leading
> to this WARN path. But currently alloc_contig_frozen_range() with
> __GFP_COMP is used by gigantic hugetlb, thus that is not possible.
> 
> How about
> 1. making sure order is bigger or equal to MAX_PAGE_ORDER,

Makes sense. As you say, hugetlb doesn't need something smaller.

> 2. adding a comment in the WARN path to prevent someone else trying to
> fix WARN path if Sashiko reports this again


Agreed.


-- 
Cheers,

David