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 6/8] PCI/IOV: Let sriov_add_vfs() own the failure unwind
Date: Fri, 11 Sep 2026 14:32:41 +0200	[thread overview]
Message-ID: <20260911123241.3312-1-sakacpav@amazon.de> (raw)
In-Reply-To: <20260911-vfopt-s1-v1-0-693271dc0226@amazon.de>

__pci_iov_add_virtfn() unwinds its own sysfs-link failure with
pci_stop_and_remove_bus_device(), which lockdep-asserts
pci_rescan_remove_lock. The next commit runs __pci_iov_add_virtfn() from
async workers that must never take or require that lock, so the unwind
has to move to the enabling task.

Leave __pci_iov_add_virtfn() reporting only and let each caller unwind
through pci_iov_remove_virtfn(), whose lookup-based design is correct at
every failure stage. sriov_add_vfs() unwinds ids 0..i inclusive on
failure of VF i, since VF i may be registered but not yet linked. The
wrapper unwinds fully before returning, because its EEH caller discards
the return code: the VF is removed through pci_iov_remove_virtfn(),
which also frees the bus it empties, and a bus this call created with
no VF registered on it is removed explicitly.

Assisted-by: LLM
Signed-off-by: Pavol Sakac <sakacpav@amazon.de>
---
 drivers/pci/iov.c | 31 ++++++++++++++++++++-----------
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index dda9303516f5..a32b2c295922 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -383,35 +383,42 @@ static int __pci_iov_add_virtfn(struct pci_dev *dev, struct pci_bus *bus,
 	pci_device_add(virtfn, virtfn->bus);
 	rc = pci_iov_sysfs_link(dev, virtfn, id);
 	if (rc)
-		goto failed1;
+		return rc;
 
 	pci_bus_add_device(virtfn);
 
 	return 0;
-
-failed1:
-	pci_stop_and_remove_bus_device(virtfn);
-	pci_dev_put(dev);
-
-	return rc;
 }
 
 int pci_iov_add_virtfn(struct pci_dev *dev, int id)
 {
 	struct pci_bus *bus;
+	bool created;
 	int rc;
 
-	bus = virtfn_add_bus(dev->bus, pci_iov_virtfn_bus(dev, id), NULL);
+	bus = virtfn_add_bus(dev->bus, pci_iov_virtfn_bus(dev, id), &created);
 	if (!bus)
 		return -ENOMEM;
 
 	rc = __pci_iov_add_virtfn(dev, bus, id);
-	if (rc)
-		virtfn_remove_bus(dev->bus, bus);
+	if (rc) {
+		pci_iov_remove_virtfn(dev, id);
+		/*
+		 * Same ownership and stale-pointer rules as the
+		 * sriov_add_vfs() bus unwind.
+		 */
+		if (created) {
+			bus = pci_find_bus(pci_domain_nr(dev->bus),
+					   pci_iov_virtfn_bus(dev, id));
+			if (bus)
+				virtfn_remove_bus(dev->bus, bus);
+		}
+	}
 
 	return rc;
 }
 
+/* Unwind primitive for partial adds: a missing VF must stay a silent no-op. */
 void pci_iov_remove_virtfn(struct pci_dev *dev, int id)
 {
 	char buf[VIRTFN_ID_LEN];
@@ -681,8 +688,10 @@ static int sriov_add_vfs(struct pci_dev *dev, u16 num_vfs)
 	kvfree(buses);
 	return 0;
 failed:
-	while (i--)
+	/* VF i may be partially added: unwind ids 0..i inclusive. */
+	do {
 		pci_iov_remove_virtfn(dev, i);
+	} while (i--);
 
 remove_buses:
 	/*
-- 
2.47.3


  parent reply	other threads:[~2026-09-11 12:32 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 ` [RFC PATCH 4/8] PCI/PM: Serialize pci_bridge_d3_update() Pavol Sakac
2026-09-11 12:47   ` 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 ` Pavol Sakac [this message]
2026-09-11 12:52   ` [RFC PATCH 6/8] PCI/IOV: Let sriov_add_vfs() own the failure unwind 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=20260911123241.3312-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.