All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: Ferran <ferran.duarri@me.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [RFC PATCH] x86/PCI: Use the only online node for root buses with no _PXM
Date: Wed, 30 Sep 2026 07:23:58 +0000	[thread overview]
Message-ID: <20260930072358.C5FD81F000FF@smtp.kernel.org> (raw)
In-Reply-To: <33c0b32e-11eb-4e3e-bb59-e349289c498b@me.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] x86/pci: num_online_nodes() check breaks NUMA locality for offline nodes
- [Low] x86/pci: faking NUMA locality to suppress out-of-tree module warnings
--

commit 8ab24ac3406319565e845067f7c37f528237c0fa
Author: Ferran <ferran.duarri@me.com>

x86/PCI: Use the only online node for root buses with no _PXM

When a host bridge has no _PXM and the Northbridge fallback finds
nothing either, pci_acpi_root_get_node() leaves every root bus at
NUMA_NO_NODE. This patch forces the node to first_online_node when
there is exactly one node online.

> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index 7cd5388edc756..cf7f9b879b42f 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -463,6 +463,13 @@ static int pci_acpi_root_get_node(struct acpi_pci_root *root)
>  	if (node != NUMA_NO_NODE && !node_online(node))
>  		node = NUMA_NO_NODE;
>  
> +	/*
> +	 * One online node means there's only one possible answer, so don't
> +	 * leave the bus at NUMA_NO_NODE just because firmware didn't say.
> +	 */
> +	if (node == NUMA_NO_NODE && num_online_nodes() == 1)
> +		node = first_online_node;

[Severity: Medium]
Could this num_online_nodes() check incorrectly bind a root bus on an offline
node to the first online node?

During system boot or PCI enumeration on multi-node setups where a subset of
nodes are temporarily offline, num_online_nodes() could evaluate to 1. This
overrides the NUMA_NO_NODE state with first_online_node.

When the offline node is brought online, would this permanent binding cause
cross-node memory allocations and latency?

Would checking num_possible_nodes() == 1 or nr_node_ids == 1 be safer here
to avoid corrupting topology on hotplug systems?

[Severity: Low]
Is it appropriate to advertise node 0 instead of NUMA_NO_NODE for root buses
lacking _PXM?

The commit message states this change is to accommodate the out-of-tree
nvidia-fs driver. NUMA_NO_NODE (-1) is the architecturally correct state when
hardware/ACPI lacks proximity data, and core subsystems handle it gracefully.

Should hardware topology be faked in the core kernel to work around an
out-of-tree driver?

> +
>  	return node;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/33c0b32e-11eb-4e3e-bb59-e349289c498b@me.com?part=1

      reply	other threads:[~2026-09-30  7:23 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-30  7:15 [RFC PATCH] x86/PCI: Use the only online node for root buses with no _PXM Ferran
2026-09-30  7:23 ` sashiko-bot [this message]

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=20260930072358.C5FD81F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=ferran.duarri@me.com \
    --cc=linux-pci@vger.kernel.org \
    --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.