From: sashiko-bot@kernel.org
To: "Brendan Jackman" <jackmanb@google.com>
Cc: linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH v4 13/18] mm: Remove __alloc_pages_node()
Date: Thu, 02 Jul 2026 11:11:03 +0000 [thread overview]
Message-ID: <20260702111103.DD2B41F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260702-alloc-trylock-v4-13-0af8ff387e80@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The patch removes `__alloc_pages_node` because it is unsafe to use with `cpu_to_node()`, which can return `NUMA_NO_NODE` (-1) during CPU hotplug, but leaves the equivalent `__folio_alloc_node` untouched, which suffers from the exact same vulnerability.
--
commit 584eaae6f16d0eb43140d0b202665ffc9212c61e
Author: Brendan Jackman <jackmanb@google.com>
mm: Remove __alloc_pages_node()
This commit removes __alloc_pages_node() since it is prone to memory
corruption on CPU hotplug if callers pass NUMA_NO_NODE from cpu_to_node().
Removing it leaves the __* variants strictly for internal memory management.
> 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 isn't a bug introduced by this patch, but does __folio_alloc_node_noprof()
suffer from the exact same vulnerability that motivated removing
__alloc_pages_node_noprof()?
If NUMA_NO_NODE (-1) is passed here, it triggers VM_BUG_ON(nid < 0) or bypasses
it in non-debug builds, leading to out-of-bounds array accesses when evaluating
warn_if_node_offline() and NODE_DATA(-1).
Looking at net/sunrpc/svc.c, there is a path that passes the result of
cpu_to_node() directly to __folio_alloc_node() without checking for
NUMA_NO_NODE:
net/sunrpc/svc.c:svc_prepare_thread() {
...
node = svc_pool_map_get_node(pool->sp_id);
rqstp->rq_scratch_folio = __folio_alloc_node(GFP_KERNEL, 0, node);
...
}
During concurrent CPU hotplug, svc_pool_map_get_node() can return NUMA_NO_NODE.
Should __folio_alloc_node() be removed or fixed in this patch as well to fully
eliminate this class of bug?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260702-alloc-trylock-v4-0-0af8ff387e80@google.com?part=13
next prev parent reply other threads:[~2026-07-02 11:11 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-02 9:49 [PATCH v4 00/18] mm: Some cleanups for page allocator APIs Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 01/18] mm/page_alloc: rename ALLOC_TRYLOCK -> ALLOC_NOLOCK Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 02/18] mm/page_alloc: some renames to clarify alloc_flags scopes Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 03/18] mm: name some args in a function declaration Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 04/18] mm: Split out internal page_alloc.h Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 05/18] mm/page_alloc: unify __alloc_frozen_pages[_nolock]_noprof() Brendan Jackman
2026-07-03 9:20 ` Vlastimil Babka (SUSE)
2026-07-02 9:49 ` [PATCH v4 06/18] mm/page_alloc: relax GFP WARN in nolock allocs Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 07/18] mm: move some stuff to mm/page_alloc.h Brendan Jackman
2026-07-02 10:28 ` sashiko-bot
2026-07-03 9:25 ` Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 08/18] perf/x86/intel: Use higher-level allocator API Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 09/18] KVM: VMX: " Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 10/18] x86/virt: " Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 11/18] sgi-xp: " Brendan Jackman
2026-07-02 10:54 ` sashiko-bot
2026-07-02 9:49 ` [PATCH v4 12/18] net/funeth: Switch to " Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 13/18] mm: Remove __alloc_pages_node() Brendan Jackman
2026-07-02 11:11 ` sashiko-bot [this message]
2026-07-02 9:49 ` [PATCH v4 14/18] mm: Move __alloc_pages() to mm/page_alloc.h Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 15/18] mm: replace __GFP_NO_CODETAG with ALLOC_NO_CODETAG Brendan Jackman
2026-07-03 2:29 ` Hao Ge
2026-07-03 9:24 ` Vlastimil Babka (SUSE)
2026-07-02 9:49 ` [PATCH v4 16/18] mm: remove the __GFP_NO_OBJ_EXT flag Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 17/18] mm/page_alloc: drop alloc_flags arg from alloc_flags_cma() Brendan Jackman
2026-07-03 9:28 ` Vlastimil Babka (SUSE)
2026-07-02 9:49 ` [PATCH v4 18/18] mm: factor out can_spin_trylock() Brendan Jackman
2026-07-02 12:28 ` sashiko-bot
2026-07-03 9:16 ` Brendan Jackman
2026-07-03 9:32 ` Vlastimil Babka (SUSE)
2026-07-03 11:43 ` Brendan Jackman
2026-07-03 9:38 ` Harry Yoo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260702111103.DD2B41F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=jackmanb@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.