Linux driver-core infrastructure
 help / color / mirror / Atom feed
From: Pavol Sakac <sakacpav@amazon.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Tejun Heo <tj@kernel.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Danilo Krummrich <dakr@kernel.org>
Cc: <driver-core@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	Xu Yang <xu.yang_2@nxp.com>,
	Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>,
	Bjorn Helgaas <bhelgaas@google.com>, <linux-pci@vger.kernel.org>,
	Alex Williamson <alex@shazbot.org>, <kvm@vger.kernel.org>,
	<nh-open-source@amazon.com>
Subject: [RFC PATCH 8/8] vfio: Opt the group and vfio-dev class devices into staged sysfs
Date: Fri, 11 Sep 2026 19:43:40 +0200	[thread overview]
Message-ID: <20260911174414.97060-8-sakacpav@amazon.de> (raw)
In-Reply-To: <20260911-vfopt-s5-v1-0-fa4cacdb6ca8@amazon.de>

The vfio group chardev and the vfio-dev class device are created once per
VF during a registration storm and satisfy the staged-sysfs opt-in
conditions trivially: class devices never match drivers, no
class_interface consumers exist for either class, and the KOBJ_ADD uevent
fires after publication, so no consumer can observe a partially built
directory. Without this, the concurrent registrations that creating the
group chardev outside vfio.group_lock unleashes convoy on the eager
kernfs_rwsem path instead.

Both devices live in class glue directories, which staged registration
covers.

Assisted-by: LLM
Signed-off-by: Pavol Sakac <sakacpav@amazon.de>
---
 drivers/vfio/group.c     | 7 +++++++
 drivers/vfio/vfio_main.c | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index 692381151303..ee41e1253f3d 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -659,6 +659,13 @@ vfio_group_find_or_create(struct device *dev, struct iommu_group *iommu_group,
 	list_add(&new->vfio_next, &vfio.group_list);
 	mutex_unlock(&vfio.group_lock);
 
+	/*
+	 * Class devices never match drivers and vfio has no class_interface
+	 * consumers, so nothing can observe the group chardev's directory
+	 * before device_add() publishes it in one step.
+	 */
+	dev_set_sysfs_staged(&new->dev);
+
 	/*
 	 * Hold back device_add()'s KOBJ_ADD until publication; on failure,
 	 * suppression also keeps the device_add() unwind from emitting an
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 423ead48aafe..7abdfbd54b9d 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -383,6 +383,9 @@ static int __vfio_register_dev(struct vfio_device *device,
 		goto err_out;
 	}
 
+	/* Staged opt-in: same conditions as vfio_group_find_or_create(). */
+	dev_set_sysfs_staged(&device->device);
+
 	ret = vfio_device_add(device);
 	if (ret)
 		goto err_out;
-- 
2.47.3


      parent reply	other threads:[~2026-09-11 17:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-11 17:43 [RFC PATCH 0/8] kernfs, driver core: staged sysfs registration Pavol Sakac
2026-09-11 17:43 ` [RFC PATCH 1/8] kernfs: factor out reusable directory helpers Pavol Sakac
2026-09-11 17:43 ` [RFC PATCH 2/8] kernfs: add staged directory creation and publication Pavol Sakac
2026-09-11 17:43 ` [RFC PATCH 3/8] sysfs: add opt-in " Pavol Sakac
2026-09-11 17:43 ` [RFC PATCH 4/8] driver core: Register opted-in devices through the staged sysfs path Pavol Sakac
2026-09-11 17:43 ` [RFC PATCH 5/8] drivers: base: test: Add KUnit suite for staged sysfs registration Pavol Sakac
2026-09-12 13:14   ` Andy Shevchenko
2026-09-11 17:43 ` [RFC PATCH 6/8] driver core: Defer uevents for devices registered in a staged window Pavol Sakac
2026-09-12 13:20   ` Andy Shevchenko
2026-09-11 17:43 ` [RFC PATCH 7/8] PCI/IOV: Register virtual functions through the staged sysfs path Pavol Sakac
2026-09-11 17:43 ` Pavol Sakac [this message]

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=20260911174414.97060-8-sakacpav@amazon.de \
    --to=sakacpav@amazon.de \
    --cc=alex@shazbot.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bartosz.golaszewski@oss.qualcomm.com \
    --cc=bhelgaas@google.com \
    --cc=dakr@kernel.org \
    --cc=driver-core@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=nh-open-source@amazon.com \
    --cc=rafael@kernel.org \
    --cc=tj@kernel.org \
    --cc=xu.yang_2@nxp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox