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

[Kefeng Wang <wangkefeng.wang@huawei.com>]

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@bytedance.com>
>>>
>>> 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...