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

[David Hildenbrand (Arm)]

On 11/2/26 10:29, Zhenghui Hao wrote:
> 
> 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.

@Zi, are you still intending to follow up on the things we discussed in that thread?

-- 
Cheers,

David