All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavol Sakac <sakacpav@amazon.de>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	"David Matlack" <dmatlack@google.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Kees Cook" <kees@kernel.org>,
	"Madhavan Srinivasan" <maddy@linux.ibm.com>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Nicholas Piggin" <npiggin@gmail.com>,
	"Christophe Leroy" <chleroy@kernel.org>,
	linuxppc-dev@lists.ozlabs.org,
	"Niklas Schnelle" <schnelle@linux.ibm.com>,
	"Benjamin Block" <bblock@linux.ibm.com>,
	"Lukas Wunner" <lukas@wunner.de>,
	"Ionut Nechita" <ionut.nechita@windriver.com>,
	nh-open-source@amazon.com
Subject: [RFC PATCH 4/8] PCI/PM: Serialize pci_bridge_d3_update()
Date: Fri, 11 Sep 2026 14:30:52 +0200	[thread overview]
Message-ID: <20260911123052.94884-1-sakacpav@amazon.de> (raw)
In-Reply-To: <20260911-vfopt-s1-v1-0-693271dc0226@amazon.de>

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>
---
 drivers/pci/pci.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index c62a315c0b4c..b2a159ef125b 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3095,17 +3095,36 @@ static int pci_dev_check_d3cold(struct pci_dev *dev, void *data)
 }
 
 /*
+ * Serializes pci_bridge_d3_update()'s bridge_d3 read-modify-writes and
+ * their upstream propagation.  Ordering: pci_rescan_remove_lock,
+ * device_lock(any) -> pci_bridge_d3_lock -> pci_bus_sem (read); no
+ * pci_walk_bus() callback may call into this path.
+ */
+static DEFINE_MUTEX(pci_bridge_d3_lock);
+
+/**
  * pci_bridge_d3_update - Update bridge D3 capabilities
  * @dev: PCI device which is changed
  *
  * Update upstream bridge PM capabilities accordingly depending on if the
  * device PM configuration was changed or the device is being removed.  The
  * change is also propagated upstream.
+ *
+ * Context: Process context. Takes and releases pci_bridge_d3_lock.
  */
 void pci_bridge_d3_update(struct pci_dev *dev)
 {
 	struct pci_dev *bridge;
 
+	/*
+	 * Unlocked fast path; the loop condition re-evaluates both checks
+	 * under the lock.
+	 */
+	bridge = pci_upstream_bridge(dev);
+	if (!bridge || !pci_bridge_d3_possible(bridge))
+		return;
+
+	mutex_lock(&pci_bridge_d3_lock);
 	while ((bridge = pci_upstream_bridge(dev)) &&
 	       pci_bridge_d3_possible(bridge)) {
 		bool remove = !device_is_registered(&dev->dev);
@@ -3148,6 +3167,7 @@ void pci_bridge_d3_update(struct pci_dev *dev)
 		/* Propagate change to upstream bridges */
 		dev = bridge;
 	}
+	mutex_unlock(&pci_bridge_d3_lock);
 }
 
 /**
@@ -3157,6 +3177,9 @@ void pci_bridge_d3_update(struct pci_dev *dev)
  * This function can be used in drivers to enable D3cold from the device
  * they handle.  It also updates upstream PCI bridge PM capabilities
  * accordingly.
+ *
+ * Context: Process context. Takes and releases pci_bridge_d3_lock;
+ * must not be called from a pci_walk_bus() callback.
  */
 void pci_d3cold_enable(struct pci_dev *dev)
 {
@@ -3174,6 +3197,9 @@ EXPORT_SYMBOL_GPL(pci_d3cold_enable);
  * This function can be used in drivers to disable D3cold from the device
  * they handle.  It also updates upstream PCI bridge PM capabilities
  * accordingly.
+ *
+ * Context: Process context. Takes and releases pci_bridge_d3_lock;
+ * must not be called from a pci_walk_bus() callback.
  */
 void pci_d3cold_disable(struct pci_dev *dev)
 {
-- 
2.47.3


  parent reply	other threads:[~2026-09-11 12:31 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-11 12:11 [RFC PATCH 0/8] PCI/IOV: Initialize virtual functions in parallel Pavol Sakac
2026-09-11 12:28 ` [RFC PATCH 1/8] PCI/IOV: Split virtfn bus handling out of pci_iov_add_virtfn() Pavol Sakac
2026-09-11 12:45   ` sashiko-bot
2026-09-11 12:29 ` [RFC PATCH 2/8] PCI/IOV: Create virtfn buses up front in sriov_add_vfs() Pavol Sakac
2026-09-11 12:46   ` sashiko-bot
2026-09-11 12:29 ` [RFC PATCH 3/8] PCI/PM: Convert pci_bridge_d3_update() recursion to iteration Pavol Sakac
2026-09-11 12:40   ` sashiko-bot
2026-09-11 12:30 ` Pavol Sakac [this message]
2026-09-11 12:47   ` [RFC PATCH 4/8] PCI/PM: Serialize pci_bridge_d3_update() sashiko-bot
2026-09-11 12:31 ` [RFC PATCH 5/8] powerpc/pci: Serialize pcibios_bus_add_device() Pavol Sakac
2026-09-11 12:55   ` sashiko-bot
2026-09-11 12:32 ` [RFC PATCH 6/8] PCI/IOV: Let sriov_add_vfs() own the failure unwind Pavol Sakac
2026-09-11 12:52   ` sashiko-bot
2026-09-11 12:33 ` [RFC PATCH 7/8] PCI/IOV: Initialize virtual functions in parallel Pavol Sakac
2026-09-11 12:43   ` sashiko-bot
2026-09-11 12:34 ` [RFC PATCH 8/8] PCI: Probe inline from node-local workqueue workers Pavol Sakac
2026-09-11 12:40   ` sashiko-bot

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=20260911123052.94884-1-sakacpav@amazon.de \
    --to=sakacpav@amazon.de \
    --cc=bblock@linux.ibm.com \
    --cc=bhelgaas@google.com \
    --cc=chleroy@kernel.org \
    --cc=dmatlack@google.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=ionut.nechita@windriver.com \
    --cc=kees@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lukas@wunner.de \
    --cc=maddy@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=nh-open-source@amazon.com \
    --cc=npiggin@gmail.com \
    --cc=schnelle@linux.ibm.com \
    /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.