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 v4 11/18] sgi-xp: Use higher-level allocator API
Date: Thu, 02 Jul 2026 10:54:22 +0000 [thread overview]
Message-ID: <20260702105423.BAA511F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260702-alloc-trylock-v4-11-0af8ff387e80@google.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] xpc_init_mq_node() incorrectly passes a NUMA node ID (nid) in place of a CPU ID to xpc_create_gru_mq_uv().
- [High] xpc_init_mq_node() fails to catch empty CPU masks, leaving global MQ pointers NULL and reporting false success.
--
commit 4df0c24c50fd7156f7d0c39d45d908827e5063f5
Author: Brendan Jackman <jackmanb@google.com>
sgi-xp: Use higher-level allocator API
This patch updates the memory allocation in xpc_create_gru_mq_uv() by
replacing __alloc_pages_node() with alloc_pages_node(). It aligns with
the deprecation of the former while preserving the existing NUMA-aware
memory allocation behavior.
> diff --git a/drivers/misc/sgi-xp/xpc_uv.c b/drivers/misc/sgi-xp/xpc_uv.c
> index 772c787268932..79c2f00ed4d70 100644
> --- a/drivers/misc/sgi-xp/xpc_uv.c
> +++ b/drivers/misc/sgi-xp/xpc_uv.c
[ ... ]
> @@ -170,9 +170,8 @@ 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);
> - page = __alloc_pages_node(nid,
> - GFP_KERNEL | __GFP_ZERO | __GFP_THISNODE,
> - pg_order);
> + page = alloc_pages_node(nid, GFP_KERNEL | __GFP_ZERO | __GFP_THISNODE,
> + pg_order);
[Severity: High]
This isn't a bug introduced by this patch, but looking at how this function
is called from xpc_init_mq_node(), is the correct CPU being passed in?
drivers/misc/sgi-xp/xpc_uv.c:xpc_init_mq_node() {
for_each_cpu(cpu, cpumask_of_node(nid)) {
xpc_activate_mq_uv =
xpc_create_gru_mq_uv(XPC_ACTIVATE_MQ_SIZE_UV, nid,
XPC_ACTIVATE_IRQ_NAME,
xpc_handle_activate_IRQ_uv);
...
It appears the loop invariant nid is passed as the cpu argument instead of
the cpu variable. Could this cause the message queue to be initialized
using the wrong physical topology resources, scrambling routing and IRQ
configuration since xpc_create_gru_mq_uv() uses the provided cpu argument for
uv_cpu_to_blade_id(), cpu_to_node(), and xpc_get_gru_mq_irq_uv()?
[Severity: High]
This is also a pre-existing issue, but does xpc_init_mq_node() properly
handle online NUMA nodes with no CPUs?
If the cpumask for the node is empty, the for_each_cpu() loop will not
execute:
drivers/misc/sgi-xp/xpc_uv.c:xpc_init_mq_node() {
for_each_cpu(cpu, cpumask_of_node(nid)) {
...
if (!IS_ERR(xpc_activate_mq_uv))
break;
}
if (IS_ERR(xpc_activate_mq_uv)) {
cpus_read_unlock();
return PTR_ERR(xpc_activate_mq_uv);
}
...
Since xpc_activate_mq_uv is initially NULL, IS_ERR(NULL) evaluates to false.
Will this bypass the error check, report false success, and leave the
pointer NULL, leading to a panic when it is dereferenced later in the driver
lifecycle?
> if (page == NULL) {
> dev_err(xpc_part, "xpc_create_gru_mq_uv() failed to alloc %d "
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260702-alloc-trylock-v4-0-0af8ff387e80@google.com?part=11
next prev parent reply other threads:[~2026-07-02 10:54 UTC|newest]
Thread overview: 23+ 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-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-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 [this message]
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
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-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-02 9:49 ` [PATCH v4 18/18] mm: factor out can_spin_trylock() Brendan Jackman
2026-07-02 12:28 ` sashiko-bot
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=20260702105423.BAA511F000E9@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