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

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

[Zhenghui Hao]

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

Fixes: e98337d11bbdf ("mm/contig_alloc: support __GFP_COMP")
Signed-off-by: Zhenghui Hao <zhenghui.hao@qq.com>
---
 mm/compaction.c | 2 +-
 mm/internal.h   | 2 ++
 mm/page_alloc.c | 9 +++++++--
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index f1b2060eb201..11ec991206bb 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -89,7 +89,7 @@ static struct page *mark_allocated_noprof(struct page *page, unsigned int order,
 }
 #define mark_allocated(...)	alloc_hooks(mark_allocated_noprof(__VA_ARGS__))
 
-static unsigned long release_free_list(struct list_head *freepages)
+unsigned long release_free_list(struct list_head *freepages)
 {
 	int order;
 	unsigned long high_pfn = 0;
diff --git a/mm/internal.h b/mm/internal.h
index 566cbd2dce48..364b288a0e2c 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -880,6 +880,8 @@ int
 isolate_migratepages_range(struct compact_control *cc,
 			   unsigned long low_pfn, unsigned long end_pfn);
 
+unsigned long release_free_list(struct list_head *freepages);
+
 #endif /* CONFIG_COMPACTION || CONFIG_CMA */
 
 struct cma;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index a8cac5e01066..6913e0f94540 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -7400,9 +7400,14 @@ int alloc_contig_frozen_range_noprof(unsigned long start, unsigned long end,
 		check_new_pages(head, order);
 		prep_new_page(head, order, gfp_mask, ALLOC_DEFAULT);
 	} else {
+		/*
+		 * isolate_freepages_range() has removed the pages from the buddy
+		 * allocator.  Put them back before undoing pageblock isolation.
+		 */
+		release_free_list(cc.freepages);
 		ret = -EINVAL;
-		WARN(true, "PFN range: requested [%lu, %lu), allocated [%lu, %lu)\n",
-		     start, end, outer_start, outer_end);
+		WARN_ONCE(1, "PFN range: requested [%lu, %lu), allocated [%lu, %lu)\n",
+			  start, end, outer_start, outer_end);
 	}
 done:
 	undo_isolate_page_range(start, end);
-- 
2.53.0

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@nvidia.com/

-- 
Cheers,

David

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@nvidia.com/
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

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@nvidia.com/
> 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

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

[Zi Yan]

On Mon Nov 2, 2026 at 5:10 AM EST, David Hildenbrand (Arm) wrote:
> 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@nvidia.com/
>> 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?

Yes, I have the patch locally and will send it out today.


-- 
Best Regards,
Yan, Zi