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

[Oscar Salvador (SUSE)]

On Thu, Nov 05, 2026 at 12:07:45PM +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>
...
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -933,9 +933,9 @@ 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;
> +	gfp |= __GFP_COMP | __GFP_NOWARN;

Do we really need __GFP_COMP | __GFP_NOWARN here?
It is my understanding that all allocations coming from hugetlb are
handled with htlb_alloc_mask(), and that should already provide
__GFP_COMP | __GFP_NOWARN.
We might have needed it when cma_alloc_frozen_compound() constructed its
own mask, but not it gets it from the caller, and that should have been
done via htlb_alloc_mask() up the chain.

So, any reason to have it here now?

 

-- 
Oscar Salvador
SUSE Labs