Re: pci_probe called concurrently in machine with 2 identical PCI devices causing race condition

[Lukas Wunner <lukas@wunner.de>]

On Thu, Jun 26, 2025 at 09:41:58AM -0600, Keith Busch wrote:
> On Thu, Jun 26, 2025 at 02:26:56PM +0200, Lukas Wunner wrote:
> > On Thu, Jun 26, 2025 at 12:20:48PM +0000, Jozef Matejcik (Nokia) wrote:
> > > However, I think this can happen in any machine with 2 identical
> > > PCI devices, because as far as I know, existing PCI drivers usually
> > > do not assume that probe function can be called from multiple threads.
> > 
> > That can happen all the time and it would be a bug in the driver
> > if it caused issues.
> 
> Wait, is that true? I thought that would only happen if the driver
> indicated probe_type PROBE_PREFER_ASYNCHRONOUS. The default appears to
> still be the same as PROBE_FORCE_SYNCHRONOUS.

You're right, and additionally PROBE_PREFER_ASYNCHRONOUS is only honored
on deferred probing.  It appears Jozef is using an out-of-tree driver,
so it's unclear if those conditions are met, but if they are, then the
driver's ->probe() hook may be executed multiple times concurrently.
I guess I went out on a limb with the above-quoted statement, so I
apologize for that.

I've just submitted a patch to honor PROBE_PREFER_ASYNCHRONOUS also on
initial probing:

https://lore.kernel.org/r/53abe6f5ac7c631f95f5d061aa748b192eda0379.1751614426.git.lukas@wunner.de

Would you mind giving it a spin to ascertain that initial probing does
happen asynchronously with it?  The nvme driver (which you co-maintain)
already opts in to async probing, so should take advantage of it right
away.  GPU drivers seem particularly guilty of lengthy probe times,
so you might want to test async probing with those as well, in order to
have quicker booting on machines used for training neural networks.

Thanks!

Lukas