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

[Qi Zheng]

Hi Oscar,

On 11/5/26 6:00 PM, Oscar Salvador (SUSE) wrote:
> 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.

Right. All current callers already supply both flags through
htlb_alloc_mask().

> 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.

Right. Now that we restore GFP propagation, setting __GFP_NOWARN here is
redundant. I'll remove it.

I'd still prefer to keep __GFP_COMP so that
cma_alloc_frozen_compound() itself guarantees compound allocation,
without requiring callers to supply the flag.

What do you think?

Thanks,
Qi

> So, any reason to have it here now?
>
>