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

[Zi Yan]

On Mon Jun 29, 2026 at 9:35 PM EDT, 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].
>
> 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
> ---
> Sashiko reports that if alloc_contig_range() with __GFP_COMP cannot
> allocate PFNs with the given range, it returns EINVAL without freeing the
> allocated PFNs and causes free memory leaks. Fix it by properly freeing the
> isolated free pages and adjusting WARN message for clarification.
> ---
>  mm/compaction.c | 2 +-
>  mm/internal.h   | 1 +
>  mm/page_alloc.c | 6 ++++--
>  3 files changed, 6 insertions(+), 3 deletions(-)
>

Hi Andrew,

I agree with David that this patch is not a proper fix to the issue.
Please drop it. I proposed an alternative[1] and want to hear David's
opinion about it. Or like David said, this WARN path should not be hit,
so there is nothing to fix.

Thanks.

[1] https://lore.kernel.org/all/DJMH7EKQ3SBB.2REYPX4LVFFTF@xxxxxxxxxx/


-- 
Best Regards,
Yan, Zi