On Mon, Jul 14, 2025 at 03:45:02PM +0200, Christoph Hellwig wrote:
> On Fri, Jul 04, 2025 at 09:38:33AM +0200, Lukas Wunner wrote:
> > The PCI core has historically not allowed drivers to opt in to async
> > probing: Even though drivers may set "PROBE_PREFER_ASYNCHRONOUS", initial
> > probing always happens synchronously. That's because the PCI core uses
> > device_attach() instead of device_initial_probe().
>
> Is it? I see frequent reordering of Qemu NVMe with the current kernel,
> and have to disable it for some of my test setups that require different
> device characteristics.
There's a PCI_DEV_ALLOW_BINDING flag in struct pci_dev which is honored
by pci_bus_match(). Initially the flag is false, so when the device is
enumerated, it's not allowed to probe. Later on in pci_bus_add_device(),
the flag is set to true and initial probing happens. It always happens
synchronously because:
pci_bus_add_device()
pci_dev_allow_binding()
device_attach()
__device_attach(dev, allow_async = false)
I guess what happens in your case is, *after* initial probing has
concluded and user space is up and running, a driver is unbound
from the device and another driver is subsequently re-bound.
E.g. "nvme" is unbound and "virtio-pci" is bound instead.
That happens synchronously, but does not prevent parallel binding
of the same driver to another device because the PCI_DEV_ALLOW_BINDING
flag is true for all devices after initial probing has happened:
bind_store()
device_driver_attach()
__driver_probe_device()
really_probe()
So that would be a second way (aside from -EPROBE_DEFER) to achieve
asynchronous probing. The commit aims at asynchronous *initial* probing
to speed up booting. I may not have made this sufficiently clear in the
commit message. :(
Thanks,
Lukas
