From: sashiko-bot@kernel.org
To: "Brendan Jackman" <jackmanb@google.com>
Cc: linux-rt-devel@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 11/16] sgi-xp: Use higher-level allocator API
Date: Mon, 29 Jun 2026 15:04:05 +0000 [thread overview]
Message-ID: <20260629150405.EC70F1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260629-alloc-trylock-v3-11-57bef0eadbc2@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] xpc_init_mq_node() incorrectly passes the node ID (nid) instead of the loop variable (cpu) to xpc_create_gru_mq_uv().
--
commit 364bc05827d5201ce117b2c0d83f21a9b64f85f3
Author: Brendan Jackman <jackmanb@google.com>
sgi-xp: Use higher-level allocator API
This commit replaces __alloc_pages_node() with alloc_pages_node() in
xpc_create_gru_mq_uv(). The __alloc_pages_node() function is being phased
out, and alloc_pages_node() works identically here while allowing
NUMA_NO_NODE if it were needed.
> diff --git a/drivers/misc/sgi-xp/xpc_uv.c b/drivers/misc/sgi-xp/xpc_uv.c
> index 772c787268932..aacff70204241 100644
> --- a/drivers/misc/sgi-xp/xpc_uv.c
> +++ b/drivers/misc/sgi-xp/xpc_uv.c
> @@ -170,7 +170,7 @@ xpc_create_gru_mq_uv(unsigned int mq_size, int cpu, char *irq_name,
> mq->mmr_blade = uv_cpu_to_blade_id(cpu);
>
> nid = cpu_to_node(cpu);
[Severity: High]
This is a pre-existing issue, but while reviewing this code, I noticed a
potential out-of-bounds access issue.
In xpc_init_mq_node(), the node ID (nid) is incorrectly passed instead of the
loop variable (cpu) to xpc_create_gru_mq_uv():
drivers/misc/sgi-xp/xpc_uv.c:xpc_init_mq_node() {
...
xpc_activate_mq_uv =
xpc_create_gru_mq_uv(XPC_ACTIVATE_MQ_SIZE_UV, nid,
XPC_ACTIVATE_IRQ_NAME,
xpc_handle_activate_IRQ_uv);
...
}
Because xpc_create_gru_mq_uv() expects a valid CPU index, passing a NUMA node
ID means the cpu parameter here contains a node ID. Since NUMA node IDs and
CPU IDs are in different ID spaces, cpu_to_node() will access the numa_node
per-CPU variable using a node ID instead of a CPU ID.
If the node ID is greater than or equal to nr_cpu_ids, will this result in an
out-of-bounds access causing a kernel panic during module load?
Even if it is within bounds, does this result in routing interrupts and
allocating memory using the topology of the wrong CPU?
> - page = __alloc_pages_node(nid,
> + page = alloc_pages_node(nid,
> GFP_KERNEL | __GFP_ZERO | __GFP_THISNODE,
> pg_order);
> if (page == NULL) {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629-alloc-trylock-v3-0-57bef0eadbc2@google.com?part=11
next prev parent reply other threads:[~2026-06-29 15:04 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260629-alloc-trylock-v3-0-57bef0eadbc2@google.com>
2026-06-29 14:00 ` [PATCH v3 00/16] mm: Some cleanups for page allocator APIs Mike Rapoport
2026-06-29 14:30 ` Brendan Jackman
2026-06-29 15:05 ` Brendan Jackman
[not found] ` <20260629-alloc-trylock-v3-4-57bef0eadbc2@google.com>
2026-06-29 14:16 ` [PATCH v3 04/16] mm: Split out internal page_alloc.h sashiko-bot
2026-06-30 13:54 ` Vlastimil Babka (SUSE)
[not found] ` <20260629-alloc-trylock-v3-13-57bef0eadbc2@google.com>
2026-06-29 15:27 ` [PATCH v3 13/16] mm: Remove __alloc_pages_node() sashiko-bot
[not found] ` <20260629-alloc-trylock-v3-9-57bef0eadbc2@google.com>
2026-06-29 15:31 ` -EXT-[PATCH v3 09/16] KVM: VMX: Use higher-level allocator API Soderlund, David
[not found] ` <20260629-alloc-trylock-v3-16-57bef0eadbc2@google.com>
2026-06-29 16:02 ` [PATCH v3 16/16] mm: remove the __GFP_NO_OBJ_EXT flag sashiko-bot
2026-06-30 10:04 ` Brendan Jackman
[not found] ` <20260629-alloc-trylock-v3-11-57bef0eadbc2@google.com>
2026-06-29 15:04 ` sashiko-bot [this message]
2026-06-29 18:47 ` [PATCH v3 11/16] sgi-xp: Use higher-level allocator API Steve Wahl
[not found] ` <20260629-alloc-trylock-v3-15-57bef0eadbc2@google.com>
2026-06-29 15:56 ` [PATCH v3 15/16] mm: replace __GFP_NO_CODETAG with ALLOC_NO_CODETAG sashiko-bot
2026-06-30 4:34 ` Hao Ge
2026-06-30 1:55 ` Hao Ge
2026-06-30 10:10 ` Brendan Jackman
2026-06-30 12:01 ` Brendan Jackman
[not found] ` <20260629-alloc-trylock-v3-1-57bef0eadbc2@google.com>
2026-06-30 12:27 ` [PATCH v3 01/16] mm/page_alloc: rename ALLOC_TRYLOCK -> ALLOC_NOLOCK Vlastimil Babka (SUSE)
[not found] ` <20260629-alloc-trylock-v3-2-57bef0eadbc2@google.com>
2026-06-30 12:38 ` [PATCH v3 02/16] mm/page_alloc: some renames to clarify alloc_flags scopes Vlastimil Babka (SUSE)
[not found] ` <20260629-alloc-trylock-v3-3-57bef0eadbc2@google.com>
2026-06-30 12:43 ` [PATCH v3 03/16] mm: name some args in a function declaration Vlastimil Babka (SUSE)
[not found] ` <20260629-alloc-trylock-v3-6-57bef0eadbc2@google.com>
2026-06-30 13:52 ` [PATCH v3 06/16] mm/page_alloc: relax GFP WARN in nolock allocs Harry Yoo
2026-06-30 16:42 ` Vlastimil Babka (SUSE)
[not found] ` <20260629-alloc-trylock-v3-5-57bef0eadbc2@google.com>
2026-06-29 14:29 ` [PATCH v3 05/16] mm/page_alloc: unify __alloc_frozen_pages[_nolock]_noprof() sashiko-bot
2026-06-29 15:27 ` Brendan Jackman
2026-06-30 13:36 ` Harry Yoo
2026-06-30 15:34 ` Vlastimil Babka (SUSE)
2026-06-30 16:56 ` Brendan Jackman
2026-06-30 17:04 ` Brendan Jackman
2026-06-30 16:16 ` Vlastimil Babka (SUSE)
[not found] ` <20260629-alloc-trylock-v3-7-57bef0eadbc2@google.com>
2026-06-30 16:42 ` [PATCH v3 07/16] mm: move some stuff to mm/page_alloc.h Vlastimil Babka (SUSE)
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=20260629150405.EC70F1F00A3A@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox