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

[Qi Zheng]

On 11/13/26 11:56 AM, Kefeng Wang wrote:
> On 11/13/2026 10:30 AM, Qi Zheng wrote:
> > On 11/12/26 7:27 PM, Kefeng Wang wrote:
> > > On 11/11/2026 2:46 PM, 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.
> > >
> > > MPOL_PREFERRED_MANY is only used for the partner allocator. Without your
> >
> > It's doesn't seem so.
> >
> > Gigantic surplus allocations already use MPOL_PREFERRED_MANY, following
> > eb02f14c4a2b ("mm/hugetlb: allow overcommitting gigantic hugepages"),
> > which predates 9bda131c6093.
> >
> > alloc_buddy_hugetlb_folio
> > --> MPOL_PREFERRED_MANY
> >      --> gfp_t gfp = gfp_mask & ~(__GFP_DIRECT_RECLAIM | __GFP_NOFAIL);
> >          folio = alloc_surplus_hugetlb_folio(h, gfp, mpoli->nid, 
> > nodemask);
> >          --> alloc_fresh_hugetlb_folio
> >              --> only_alloc_fresh_hugetlb_folio
> >                  --> alloc_gigantic_frozen_folio
> >                      --> hugetlb_cma_alloc_frozen_folio
> >                          --> cma_alloc_frozen_compound
> >
> > Before 9bda131c6093, cma_alloc_folio() forwarded the caller's GFP mask.
> > The conversion to cma_alloc_frozen_compound() replaced it with
> > GFP_KERNEL, re-enabling direct reclaim during the preferred-node
> > attempt.
>
> Oh, I forgot about that commit. The naming and some of the comments are 
> misleading because alloc_buddy_hugetlb_folio/alloc_surplus_hugetlb_folio
> can allocate both buddy and gigantic folios (which can be allocated from
> CMA).
>
> Maybe rename alloc_buddy_hugetlb_folio to hugetlb_alloc_surplus_folio,
> or other names...

Naming is difficult. ;)

The Hugetlb implementation seems quite messy in many places; let’s focus
on fixing the issues first.