Re: [PATCH v3 13/16] mm: Remove __alloc_pages_node()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incomplete API refactoring leaves `__folio_alloc_node()` and its external callers vulnerable to the CPU hotplug hazard the patch intends to fix.
--

commit 1c3f10897a9f9fbcd231ced2981c00e238f22315
Author: Brendan Jackman <jackmanb@xxxxxxxxxx>

mm: Remove __alloc_pages_node()

This commit removes the __alloc_pages_node() API to reduce the API
surface and prevent issues where callers using cpu_to_node() pass
NUMA_NO_NODE during CPU hotplug, leading to memory corruption or panics.

> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 01d6d2591f49e..3bf55a5f9143e 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
[ ... ]
> @@ -256,21 +256,6 @@ static inline void warn_if_node_offline(int this_node, gfp_t gfp_mask)
>  	dump_stack();
>  }
>  
> -/*
> - * Allocate pages, preferring the node given as nid. The node must be valid and
> - * online. For more general interface, see alloc_pages_node().
> - */
> -static inline struct page *
> -__alloc_pages_node_noprof(int nid, gfp_t gfp_mask, unsigned int order)
> -{
> -	VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
> -	warn_if_node_offline(nid, gfp_mask);
> -
> -	return __alloc_pages_noprof(gfp_mask, order, nid, NULL);
> -}
> -
> -#define  __alloc_pages_node(...)		alloc_hooks(__alloc_pages_node_noprof(__VA_ARGS__))
> -
>  static inline
>  struct folio *__folio_alloc_node_noprof(gfp_t gfp, unsigned int order, int nid)
>  {

[Severity: High]
This is a pre-existing issue, but does __folio_alloc_node_noprof() and its 
wrappers need the same treatment?

I noticed it still lacks the NUMA_NO_NODE fallback, which can be triggered by 
existing external callers. For instance, in net/sunrpc/svc.c, 
svc_pool_map_get_node() uses cpu_to_node(), which can return NUMA_NO_NODE (-1) 
during CPU hotplug:

net/sunrpc/svc.c:svc_pool_map_get_node() {
    ...
    if (m->mode == SVC_POOL_PERCPU)
        return cpu_to_node(m->pool_to[pidx]);
    ...
}

This returned node ID is then passed directly to __folio_alloc_node() in 
svc_prepare_thread():

net/sunrpc/svc.c:svc_prepare_thread() {
    ...
    rqstp->rq_scratch_folio = __folio_alloc_node(GFP_KERNEL, 0, node);
    if (!rqstp->rq_scratch_folio)
        goto out_enomem;
    ...
}

Could this trigger the same VM_BUG_ON(nid < 0) or out-of-bounds array access 
that this commit aims to resolve?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629-alloc-trylock-v3-0-57bef0eadbc2@xxxxxxxxxx?part=13