Re: [RFC PATCH 4/8] PCI/PM: Serialize pci_bridge_d3_update()

[sashiko-bot@kernel.org]

> pci_bridge_d3_update() does an unlocked read-modify-write of
> bridge->bridge_d3, and its callers are not mutually serialized: the
> d3cold_allowed sysfs write and the driver-context D3cold helpers hold
> neither pci_rescan_remove_lock nor device_lock. A concurrent write can
> lose an update and leave bridge_d3 stale, costing a wrong D3cold decision
> rather than memory safety. An upcoming change runs pci_bus_add_device()
> for sibling VFs concurrently, making sibling additions concurrent callers
> too, so this must land first.
> 
> Add a mutex around the whole update, taken once for the propagation
> loop. A device with no D3cold-capable port above it returns before the
> mutex, so the common add is not funneled through a global lock, and the
> loop re-evaluates both conditions under it. The mutex serializes the
> updaters against each other only; the d3cold_allowed store itself still
> writes an adjacent bit of the same word unlocked, a pre-existing
> exposure this change neither widens nor closes. The resulting order is
> pci_rescan_remove_lock, device_lock(any) -> pci_bridge_d3_lock ->
> pci_bus_sem (read), so pci_bridge_d3_lock must never be acquired while
> holding pci_bus_sem and no pci_walk_bus() callback may call into this
> path.
> 
> The race dates back to commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into
> D3 during suspend"), is theoretical with no known report, and so
> carries no Fixes: tag and no stable designation; it claims no measured
> performance contribution.
> 
> Assisted-by: LLM
> Signed-off-by: Pavol Sakac <sakacpav@amazon.de>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911-vfopt-s1-v1-0-693271dc0226@amazon.de?part=4