From: sashiko-bot@kernel.org
To: "Maciej Grochowski" <Maciej.Grochowski@sony.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [RFC PATCH v2 2/2] PCI: Allow hpbussize for specific hotplug bridges
Date: Tue, 03 Nov 2026 18:41:56 +0000 [thread overview]
Message-ID: <sashiko-outbox-195855@kernel.org> (raw)
In-Reply-To: <4ba0c23099e4a4f5ade2b4754871dfbcf896f7dc.1793724065.git.Maciej.Grochowski@sony.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] PCI: child bus extension in pci_scan_child_bus_extend() steals sibling buses
- [Medium] PCI: unsigned underflow clamping buses in pci_scan_child_bus_extend()
--
commit be51a5abd9a8e4940755184950c4647a492d014d
Author: Maciej Grochowski <maciej.grochowski@sony.com>
PCI: Allow hpbussize for specific hotplug bridges
This commit extends the pci=hpbussize= boot parameter to accept per-bridge
bus count reservations in the form <count>@<pci_dev>, recomputing the
share of spare bus numbers for unconfigured hotplug bridges on a bus and
applying the scoped minimum when scanning the bridge's child bus.
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 9a178e0e5f7f4..b79a931edce55 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
[ ... ]
> @@ -3163,7 +3228,16 @@ static unsigned int pci_scan_child_bus_extend(struct pci_bus *bus,
> * Distribute the extra buses between hotplug
> * bridges if any.
> */
> - buses = available_buses / hotplug_bridges;
> + if (hotplug_reserve && available_buses) {
> + if (!dev->subordinate) {
> + reserve = pci_hotplug_bus_reserve(dev);
> + buses = available_buses + 1 > used_buses ?
> + available_buses + 1 - used_buses : 0;
> + buses = pci_hotplug_bus_share(bus, dev, buses);
> + }
> + } else {
> + buses = available_buses / hotplug_bridges;
> + }
> buses = min(buses, available_buses - used_buses + 1);
> }
[Severity: Medium]
Can available_buses - used_buses + 1 underflow in unsigned arithmetic here?
Before calling pci_hotplug_bus_share(), this checks whether
available_buses + 1 > used_buses and passes 0 when used_buses is larger
(for example, when SR-IOV buses plus the one-bus-per-bridge count from the
first pass exceed available_buses + 1, or after earlier bridges consumed
more buses than available_buses).
However, pci_hotplug_bus_share() unconditionally returns at least reserve:
reserve = pci_hotplug_bus_reserve(bridge) ?: pci_hotplug_bus_size;
return max(reserve, share);
When min(buses, available_buses - used_buses + 1) then runs without that
guard, available_buses - used_buses + 1 wraps around to a large unsigned
value, leaving the non-zero buses count from pci_hotplug_bus_share()
unclamped instead of clamping it to 0.
>
> cmax = max;
> max = pci_scan_bridge_extend(bus, dev, cmax, buses, 1);
> /* One bus is already accounted so don't add it again */
> if (max - cmax > 1)
> used_buses += max - cmax - 1;
> +
> + if (reserve > max - cmax)
> + pci_warn(dev, "only %u of %u bus numbers available\n",
> + max - cmax, reserve);
> + else if (reserve)
> + pci_info(dev, "reserving %u bus numbers\n", max - cmax);
> }
>
> /*
> @@ -3180,7 +3260,10 @@ static unsigned int pci_scan_child_bus_extend(struct pci_bus *bus,
> * bus number if there is room.
> */
> if (bus->self && bus->self->is_hotplug_bridge) {
> - used_buses = max(available_buses, pci_hotplug_bus_size - 1);
> + unsigned long bus_size = pci_hotplug_bus_reserve(bus->self) ?:
> + pci_hotplug_bus_size;
> +
> + used_buses = max(available_buses, bus_size - 1);
[Severity: High]
When a hotplug bridge's scoped reservation is clamped by the parent bus in
pci_scan_child_bus_extend() so that 1 bus number remains per subsequent
sibling bridge, won't taking max(available_buses, bus_size - 1) on the
child bus override that clamp and consume the sibling bridges' buses?
On the parent bus, pci_scan_child_bus_extend() clamps the bridge's share
via:
buses = min(buses, available_buses - used_buses + 1);
and passes that clamped count to pci_scan_bridge_extend(). In pass 1,
pci_scan_bridge_extend() creates the child bus with its temporary end set
to the parent's busn_res.end before recursing:
pci_bus_insert_busn_res(child, next_busnr,
bus->busn_res.end);
...
if (available_buses)
available_buses--;
...
max = pci_scan_child_bus_extend(child, available_buses);
Inside the recursive pci_scan_child_bus_extend(child, available_buses)
call, bus->self is that hotplug bridge. Using max(available_buses,
bus_size - 1) replaces the parent-clamped available_buses with the
unclamped bus_size - 1, and only bounds max = start + used_buses against
child->busn_res.end (which is still the parent bus's busn_res.end).
For example, if 5 hotplug downstream ports share 15 buses and port 3
requests hpbussize=12 after ports 0..2 take 1 bus each, the parent clamps
port 3 to 11 buses so 1 bus remains for port 4. In the child scan for port
3, available_buses is 10 while bus_size - 1 is 11, so max(10, 11) extends
port 3 all the way to the parent's busn_res.end, leaving no bus number for
port 4 and suppressing the "only %u of %u bus numbers available" warning.
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1793724065.git.Maciej.Grochowski@sony.com?part=2
prev parent reply other threads:[~2026-11-03 18:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 18:27 [RFC PATCH v2 0/2] PCI: Reserve resources for a delayed hotplug subtree Maciej Grochowski
2026-11-03 18:27 ` [RFC PATCH v2 1/2] PCI: Allow hpmmiosize and hpmmioprefsize for specific hotplug bridges Maciej Grochowski
2026-11-03 18:43 ` sashiko-bot
2026-11-03 18:27 ` [RFC PATCH v2 2/2] PCI: Allow hpbussize " Maciej Grochowski
2026-11-03 18:41 ` 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=sashiko-outbox-195855@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Maciej.Grochowski@sony.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.