When a device is hot-plugged, the drivers_autoprobe sysfs attribute is
not checked. This means that drivers_autoprobe is not working as
intended, e.g. hot-plugged PCIe devices will still be autoprobed and
bound to drivers even with drivers_autoprobe disabled.

Make sure all devices check drivers_autoprobe by pushing the
drivers_autoprobe check into device_initial_probe. This will only
affect devices on the PCI bus for now as device_initial_probe is only
called by pci_bus_add_device and bus_probe_device (but bus_probe_device
already checks for autoprobe). In particular for the PCI devices, only
hot-plugged PCIe devices/VFs should be affected as the default value of
pci/drivers_autoprobe remains 1 and can only be cleared from userland.

Any future callers of device_initial_probe will respsect the
drivers_autoprobe sysfs attribute, but this should be the intended
purpose of drivers_autoprobe.

Signed-off-by: Vincent Liu <vincent.liu@nutanix.com>
---
v1->v2: Change commit subject to include driver core (no code change)
	https://lore.kernel.org/20251001151508.1684592-1-vincent.liu@nutanix.com
---
 drivers/base/bus.c |  3 +--
 drivers/base/dd.c  | 10 +++++++++-
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 5e75e1bce551..320e155c6be7 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -533,8 +533,7 @@ void bus_probe_device(struct device *dev)
 	if (!sp)
 		return;
 
-	if (sp->drivers_autoprobe)
-		device_initial_probe(dev);
+	device_initial_probe(dev);
 
 	mutex_lock(&sp->mutex);
 	list_for_each_entry(sif, &sp->interfaces, node)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 13ab98e033ea..37fc57e44e54 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -1077,7 +1077,15 @@ EXPORT_SYMBOL_GPL(device_attach);
 
 void device_initial_probe(struct device *dev)
 {
-	__device_attach(dev, true);
+	struct subsys_private *sp = bus_to_subsys(dev->bus);
+
+	if (!sp)
+		return;
+
+	if (sp->drivers_autoprobe)
+		__device_attach(dev, true);
+
+	subsys_put(sp);
 }
 
 /*
-- 
2.43.7

On Mon, Oct 13, 2025 at 07:14:59PM +0100, Vincent Liu wrote:
> When a device is hot-plugged, the drivers_autoprobe sysfs attribute is
> not checked. This means that drivers_autoprobe is not working as
> intended, e.g. hot-plugged PCIe devices will still be autoprobed and
> bound to drivers even with drivers_autoprobe disabled.
> 
> Make sure all devices check drivers_autoprobe by pushing the
> drivers_autoprobe check into device_initial_probe. This will only
> affect devices on the PCI bus for now as device_initial_probe is only
> called by pci_bus_add_device and bus_probe_device (but bus_probe_device
> already checks for autoprobe). In particular for the PCI devices, only
> hot-plugged PCIe devices/VFs should be affected as the default value of
> pci/drivers_autoprobe remains 1 and can only be cleared from userland.
> 
> Any future callers of device_initial_probe will respsect the
> drivers_autoprobe sysfs attribute, but this should be the intended
> purpose of drivers_autoprobe.
> 
> Signed-off-by: Vincent Liu <vincent.liu@nutanix.com>
> ---
> v1->v2: Change commit subject to include driver core (no code change)
> 	https://lore.kernel.org/20251001151508.1684592-1-vincent.liu@nutanix.com

What commit id does this fix?  What devices cause this to happen today
that are seeing this issue?  Should this be backported to older kernels?

thanks,

greg k-h

On 14 Oct 2025, at 06:14, Greg KH <gregkh@linuxfoundation.org> wrote:

> What commit id does this fix? 

I am not entirely sure if there is a particular commit that causes this issue,
the device_attach call was added in pci/bus.c 58d9a38f6fac, and then the
device_add was removed in 4f535093cf8f6. At this point I think the
drivers_autoprobe stopped working because driver_attach that’s left in
pci_bus_add_device does not check for that.

The drivers_autoprobe check in base/bus.c has been there a long time 
since b8c5cec23d5c.

> What devices cause this to happen today that are seeing this issue?

I am observing this for hot-plugged PCIe devices and VFs.

> Should this be backported to older kernels?

I suppose not since this was not working for a long time?

Thanks,
Vincent

> On 14 Oct 2025, at 13:10, Vincent Liu <vincent.liu@nutanix.com> wrote:
> 
> On 14 Oct 2025, at 06:14, Greg KH <gregkh@linuxfoundation.org> wrote:
> 
>> What commit id does this fix?
> 
> I am not entirely sure if there is a particular commit that causes this issue,
> the device_attach call was added in pci/bus.c 58d9a38f6fac, and then the
> device_add was removed in 4f535093cf8f6. At this point I think the
> drivers_autoprobe stopped working because driver_attach that’s left in
> pci_bus_add_device does not check for that.
> 
> The drivers_autoprobe check in base/bus.c has been there a long time 
> since b8c5cec23d5c.
> 
>> What devices cause this to happen today that are seeing this issue?
> 
> I am observing this for hot-plugged PCIe devices and VFs.
> 
>> Should this be backported to older kernels?
> 
> I suppose not since this was not working for a long time?
> 

Are you happy with this reply Greg? Do you want me to update the commit
message to include some of these commit ids?

Thanks,
Vincent

On Tue, Oct 21, 2025 at 12:49:21PM +0000, Vincent Liu wrote:
> > On 14 Oct 2025, at 13:10, Vincent Liu <vincent.liu@nutanix.com> wrote:
> > 
> > On 14 Oct 2025, at 06:14, Greg KH <gregkh@linuxfoundation.org> wrote:
> > 
> >> What commit id does this fix?
> > 
> > I am not entirely sure if there is a particular commit that causes this issue,
> > the device_attach call was added in pci/bus.c 58d9a38f6fac, and then the
> > device_add was removed in 4f535093cf8f6. At this point I think the
> > drivers_autoprobe stopped working because driver_attach that’s left in
> > pci_bus_add_device does not check for that.
> > 
> > The drivers_autoprobe check in base/bus.c has been there a long time 
> > since b8c5cec23d5c.
> > 
> >> What devices cause this to happen today that are seeing this issue?
> > 
> > I am observing this for hot-plugged PCIe devices and VFs.
> > 
> >> Should this be backported to older kernels?
> > 
> > I suppose not since this was not working for a long time?
> > 
> 
> Are you happy with this reply Greg? Do you want me to update the commit
> message to include some of these commit ids?

Please do.