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

[David Hildenbrand (Arm)]

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/

-- 
Cheers,

David