Re: [PATCH] mm/page_alloc: release isolated freepages on compound range mismatch

[Zhenghui Hao]

On 2026/11/2 17:11, David Hildenbrand (Arm) wrote:
> On 11/2/26 10:06, Zhenghui Hao wrote:
>> alloc_contig_frozen_range_noprof() isolates [outer_start, outer_end)
>> before checking whether a __GFP_COMP request exactly matches the
>> allocated range.  If it does not, the function returns -EINVAL without
>> releasing cc.freepages, leaking the isolated pages.
>>
>> Call release_free_list() before returning -EINVAL, while the pageblock
>> is still isolated, matching the cleanup already used when
>> isolate_freepages_range() fails.
>>
>> Use WARN_ONCE() as well: the condition is reachable through the exported
>> API, and repeated invalid calls should not flood dmesg.
>>
>> Tested with an order-9 free pageblock and a one-page __GFP_COMP
>> subrange:
>>   before: free_buddy=0, leaked=512/512
>>   after:  free_buddy=1, leaked=0/512
> How did you reproduce this? Using a hacky kernel module?
>
>> Fixes: e98337d11bbdf ("mm/contig_alloc: support __GFP_COMP")
> I thought we discussed this in the past: if you are able to trigger the WARN
> something is messed up already.
>
>
> And indeed, same patch already here, SMH
>
> https://lore.kernel.org/linux-mm/20260629-free-pfn-on-alloc-contig-range-error-path-v1-1-496ff9ca22db@xxxxxxxxxx/
Thanks for the pointer, and sorry for the duplicate -- I missed the
earlier thread.

You're right on both points: the reproducer was a synthetic module, not a
real workload, and being able to trigger the WARN means the underlying
path or validation needs fixing rather than papering over it with
WARN_ONCE.

I'll drop this version and follow the existing thread. I'll check whether
the earlier patch is still pending and only send an update if there is a
real delta on the current tree.

Thanks,
Zhenghui