Re: [PATCH v3 3/3] mm: hugetlb: fix GFP mask propagation to CMA

[Oscar Salvador (SUSE)]

On Sat, Nov 07, 2026 at 06:30:47PM +0800, Qi Zheng wrote:
> From: Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx>
> 
> cma_alloc_frozen_compound() uses GFP_KERNEL, allowing direct reclaim
> during the first MPOL_PREFERRED_MANY allocation attempt even though
> the caller clears __GFP_DIRECT_RECLAIM.
> 
> Pass the caller's GFP mask through the helper so CMA respects its
> reclaim constraints when trying the preferred nodes.
> 
> Fixes: 9bda131c6093 ("mm: cma: add cma_alloc_frozen{_compound}()")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx>
> Acked-by: Muchun Song <muchun.song@xxxxxxxxx>
> Reviewed-by: Jose A. Perez de Azpillaga <azpijr@xxxxxxxxx>

Reviewed-by: Oscar Salvador (SUSE) <osalvador@xxxxxxxxxx>

A comment below:

> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -933,9 +933,10 @@ struct page *cma_alloc_frozen(struct cma *cma, unsigned long count,
>  	return __cma_alloc_frozen(cma, count, align, gfp);
>  }
>  
> -struct page *cma_alloc_frozen_compound(struct cma *cma, unsigned int order)
> +struct page *cma_alloc_frozen_compound(struct cma *cma, unsigned int order, gfp_t gfp)
>  {
> -	gfp_t gfp = GFP_KERNEL | __GFP_COMP | __GFP_NOWARN;
> +	if (WARN_ON_ONCE(!(gfp & __GFP_COMP)))
> +		return NULL;

I think this needs a comment explaining why we are checking for __GFP_COMP,
because it might not be obvious to the casual reader.
Something like:

 "The only caller of cma_alloc_frozen_compound() is hugetlb, and hugetlb
  constructs its gfp mask via htlb_alloc_mask(), which already sets
  __GFP_COMP. Check here for usecases bypassing htlb_alloc_mask()."


Maybe in the future we do have some other users of this function which are outside
of the hugetlb realm, but if we are propagating the gfp mask down the chain to this
point, we do have to check that those users are also setting __GFP_COMP.
  
 

-- 
Oscar Salvador
SUSE Labs