Re: [PATCH v5] PCI: Fix BAR resize for devices on a root bus

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] Stricter resource assignment check on root bus fails BAR resize if optional resources (like ROM BARs) cannot be assigned.

Pre-existing issues:
- [High] Space stolen by other devices during resource assignment breaks the rollback in the `restore` path.
--

commit 72e60fcada94a7186e28648f6c748fdfeb09e254
Author: Liz Fong-Jones <lizf@honeycomb.io>

PCI: Fix BAR resize for devices on a root bus

pci_do_resource_release_and_resize() releases the device BARs that share a
bridge window with the BAR being resized, but when the device sits directly on
a root bus it skips resource assignment and leaves the BARs unassigned.
When there is no upstream bridge, this patch calls pci_bus_assign_resources()
on the root bus to place the released BARs. A stricter validation is then used
to fail if any unplaced resources remain.

Link: https://bugs.launchpad.net/ubuntu/+source/linux-hwe-7.0/+bug/2159596

> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index e8c94aa1d3c12..ed16ef7c26fa7 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c

[ ... ]

> @@ -2415,13 +2418,21 @@ int pci_do_resource_release_and_resize(struct pci_dev *pdev, int resno, int size
>  
>  	pci_resize_resource_set_size(pdev, resno, size);
>  
> -	if (!bus->self)
> -		goto out;
> +	if (bridge) {
> +		ret = pbus_reassign_bridge_resources(bus, res, &saved);
> +		if (ret)
> +			goto restore;
> +	} else {
> +		/* No bridge window to adjust; let the core reassign the bus. */
> +		pci_bus_assign_resources(bus);
>  
> -	down_read(&pci_bus_sem);
> -	ret = pbus_reassign_bridge_resources(bus, res, &saved);
> -	if (ret)
> -		goto restore;
> +		list_for_each_entry(dev_res, &saved, list) {
> +			if (!resource_assigned(dev_res->res)) {
> +				ret = -ENOSPC;
> +				goto restore;
                                ^^^^^^^^^^^^

[Severity: High]
This isn't a bug introduced by this patch, but does jumping to the restore
path risk leaving the device unassigned if the original resource space was
stolen?

If another device on the same bus is assigned into the space just freed by the
target device during pci_bus_assign_resources(), the restore path in
pci_do_resource_release_and_resize() will fail to claim it back:

	list_for_each_entry(dev_res, &saved, list) {
		...
		if (pci_claim_resource(dev, i))
			continue;
		...
	}

Since pci_claim_resource() fails when the space is occupied, could the device
be left with unassigned BARs and completely broken?

> +			}

[Severity: High]
Does this stricter check unintentionally fail the BAR resize if an optional
resource (like a ROM BAR) could not be assigned?

If a driver requests a BAR resize and pci_bus_assign_resources() succeeds for
the resized BAR but leaves an optional ROM BAR unassigned, the check for
!resource_assigned(dev_res->res) will trigger a rollback with -ENOSPC.

Could this functionally break valid BAR resizes on root buses just because an
optional resource was unassigned?

> +		}
> +	}
>  
>  out:
>  	up_read(&pci_bus_sem);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260908-pci-rebar-root-bus-v5-1-a210f405ea81@honeycomb.io?part=1