Re: [PATCH 3/4] mm: hugetlb: skip CMA when direct reclaim is disallowed

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mm: hugetlb: hugetlb_cma_alloc_frozen_folio() breaks MPOL_PREFERRED_MANY
--

commit c96d52d66d643a77abaa96a17e392b7ab0f36ccd
Author: Qi Zheng <qi.zheng@linux.dev>

mm: hugetlb: skip CMA when direct reclaim is disallowed

This commit updates hugetlb_cma_alloc_frozen_folio() to return NULL when
gfpflags_allow_blocking(gfp_mask) is false, avoiding direct reclaim inside
cma_alloc_frozen_compound() when __GFP_DIRECT_RECLAIM was cleared by the
caller.

> diff --git a/mm/hugetlb_cma.c b/mm/hugetlb_cma.c
> index dde1c866406fb..90f8d718a1f16 100644
> --- a/mm/hugetlb_cma.c
> +++ b/mm/hugetlb_cma.c
> @@ -59,7 +59,7 @@ struct folio *hugetlb_cma_alloc_frozen_folio(int order, gfp_t gfp_mask,
>  	const nodemask_t *nmask;
>  	unsigned int cpuset_mems_cookie;
>  
> -	if (!hugetlb_cma_size)
> +	if (!hugetlb_cma_size || !gfpflags_allow_blocking(gfp_mask))
>  		return NULL;

[Severity: Medium]
Does returning NULL from hugetlb_cma_alloc_frozen_folio() whenever
!gfpflags_allow_blocking(gfp_mask) break MPOL_PREFERRED_MANY for gigantic
surplus HugeTLB allocations?

In mm/hugetlb.c, alloc_buddy_hugetlb_folio() implements MPOL_PREFERRED_MANY
as a two-pass allocation:

mm/hugetlb.c:alloc_buddy_hugetlb_folio() {
	if (mpoli->mode == MPOL_PREFERRED_MANY) {
		gfp_t gfp = gfp_mask & ~(__GFP_DIRECT_RECLAIM | __GFP_NOFAIL);

		folio = alloc_surplus_hugetlb_folio(h, gfp, mpoli->nid,
						    nodemask);

		/* Fallback to all nodes if page==NULL */
		nodemask = NULL;
	}

	if (!folio) {
		folio = alloc_surplus_hugetlb_folio(h, gfp_mask, mpoli->nid,
						    nodemask);
	}
}

This reaches hugetlb_cma_alloc_frozen_folio() via:

  alloc_buddy_hugetlb_folio()
    -> alloc_surplus_hugetlb_folio()
      -> alloc_fresh_hugetlb_folio()
        -> only_alloc_fresh_hugetlb_folio()
          -> alloc_gigantic_frozen_folio()
            -> hugetlb_cma_alloc_frozen_folio()

On the first pass, __GFP_DIRECT_RECLAIM is cleared while nodemask points to
the preferred nodes (pol->nodes), and on the second pass nodemask is cleared
to NULL. Because hugetlb_cma_alloc_frozen_folio() now returns NULL on the
first pass, it never sees the MPOL_PREFERRED_MANY nodemask.

In mm/hugetlb.c:alloc_gigantic_frozen_folio():

	folio = hugetlb_cma_alloc_frozen_folio(order, gfp_mask, nid, nodemask);
	if (folio)
		return folio;

	if (hugetlb_cma_exclusive_alloc())
		return NULL;

	folio = (struct folio *)alloc_contig_frozen_pages(1 << order, gfp_mask,
							  nid, nodemask);

When hugetlb_cma_exclusive_alloc() is false, returning NULL from
hugetlb_cma_alloc_frozen_folio() on the first pass falls through to
alloc_contig_frozen_pages() on the preferred nodes, bypassing the dedicated
hugetlb_cma pool on the preferred nodes in favor of non-CMA memory.

When hugetlb_cma_exclusive_alloc() is true (or when non-CMA allocation fails
on the preferred nodes), the first pass returns NULL and the second pass
invokes hugetlb_cma_alloc_frozen_folio() with nodemask set to NULL. Since
mm/mempolicy.c:policy_nodemask() leaves *nid as numa_node_id() when
pol->home_node is NUMA_NO_NODE:

mm/mempolicy.c:policy_nodemask() {
	case MPOL_PREFERRED_MANY:
		nodemask = &pol->nodes;
		if (pol->home_node != NUMA_NO_NODE)
			*nid = pol->home_node;
		break;
}

hugetlb_cma_alloc_frozen_folio() on the second pass tries
hugetlb_cma[numa_node_id()] and then iterates cpuset_current_mems_allowed
from node 0, allocating from non-preferred CMA nodes even when preferred
nodes in pol->nodes have free CMA pages.

Prior to commit 9bda131c6093 ("mm: cma: add cma_alloc_frozen{_compound}()"),
cma_alloc_folio() forwarded gfp_mask down to alloc_contig_frozen_range(),
where __alloc_contig_verify_gfp_mask() preserved the cleared
__GFP_DIRECT_RECLAIM bit so CMA on the preferred nodemask was tried on the
first pass without entering direct reclaim. Would forwarding gfp_mask to
cma_alloc_frozen_compound() (in mm/cma.c) preserve both the non-reclaiming
first pass and the MPOL_PREFERRED_MANY nodemask?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1793692578.git.zhengqi.arch@bytedance.com?part=3