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

[Lance Yang]

On Tue, Jun 30, 2026 at 03:39:56PM +0200, David Hildenbrand (Arm) wrote:
>On 6/30/26 09:44, Vlastimil Babka (SUSE) wrote:
>> On 6/30/26 03:35, Zi Yan wrote:
>>> When using __GFP_COMP in alloc_contig_frozen_range(), if the allocated
>>> range does not match the requested one, the code errors out with EINVAL
>>> without freeing the allocated PFNs and causes free page leaks. Fix it by
>>> calling release_free_list() in the error path.
>>>
>>> The issue is reported by Sashiko[1].
>> 
>> So this?
>> Reported-by: Sashiko <sashiko-bot@xxxxxxxxxx>
>> 
>>> Fixes: e98337d11bbd ("mm/contig_alloc: support __GFP_COMP")
>>> Link: https://sashiko.dev/#/patchset/20260628-keep-subpage-private-zero-at-free-v1-0-f4ce3930d10f@xxxxxxxxxx [1]
>>> Signed-off-by: Zi Yan <ziy@xxxxxxxxxx>
>>> Cc: stable@xxxxxxxxxxxxxxx
>> 
>> 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*.

FWIW, this patch looks fine defensively, but probably not a stable
material unless we know a real caller can hit it :)

Cheers, Lance