Re: [PATCH v3] PCI: Accept AtomicOps already enabled by the hypervisor

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pci: atomic capabilities check bypass in headless topologies
--

commit 7a2c6321c34255d72f250ecd35fa5e1846785e21
Author: Nikola Prica <nikola.prica@amd.com>

PCI: Accept AtomicOps already enabled by the hypervisor

In passthrough guests without a visible Root Port, this commit allows
pci_enable_atomic_ops_to_root() to return success if AtomicOps are already
enabled by the hypervisor.

> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b2879a6be5f80..62729ade496fc 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3769,8 +3769,18 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>  	}
>  
>  	root = pcie_find_root_port(dev);
> -	if (!root)
> +	if (!root) {
> +		/*
> +		 * A hypervisor may expose a headless topology with no
> +		 * visible root port.  If it has already set AtomicOp
> +		 * Requester Enable, there is nothing more to do.
> +		 */
> +		pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
> +		if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
> +			return 0;

[Severity: High]
Does this bypass the cap_mask size verification in headless topologies?

pci_enable_atomic_ops_to_root() requires a cap_mask parameter (e.g.,
PCI_EXP_DEVCAP2_ATOMIC_COMP64) to verify that the physical Completer supports
the specific atomic sizes required by the driver.

In the newly added headless topology path (!root), the function checks if the
PCI_EXP_DEVCTL2_ATOMIC_REQ bit is already set on the endpoint. If the bit is
set, it returns 0 (success), completely discarding the caller's cap_mask size
requirements.

The ATOMIC_REQ flag is merely a boolean enable bit for initiating atomics; it
does not guarantee that the physical Completer supports the specific sizes
requested in cap_mask.

If a hypervisor or host enables Atomics for 32-bit sizes, setting ATOMIC_REQ,
but the guest driver requires 64-bit or 128-bit Atomics, this function will
falsely return success. The guest driver will then issue unsupported 64/128-bit
Atomics, which the physical hardware will reject with an Unsupported Request
(UR) fault, potentially triggering an AER and crashing the system.

> +
>  		return -EINVAL;
> +	}
>  
>  	pcie_capability_read_dword(root, PCI_EXP_DEVCAP2, &cap);
>  	if ((cap & cap_mask) != cap_mask)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918092857.648810-1-nikprica@amd.com?part=1