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

[Zi Yan]

On Fri Jul 10, 2026 at 10:45 AM EDT, David Hildenbrand (Arm) wrote:
> 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.

Thanks for the confirmation. I will submit a new version following these
ideas.

-- 
Best Regards,
Yan, Zi