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

[Qi Zheng <qi.zheng@linux.dev>]

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

Naming is difficult. ;)

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