(Cc: Dmitry)

On Tue Mar 10, 2026 at 10:03 PM CET, Robin Murphy wrote:

[ +driver-core maintainers - async probe question below ]

<snip>

I'm guessing it maybe wasn't anticipated to have bus drivers calling
device_initial_probe() from within async in the first place?

I think this is not limited to device_initial_probe(), device_attach() or even
device_add() would have the same problem. I.e. the driver core simply does not
consider whether it is already running in an async handler when it is requested
to run probe() synchronously.

A simple workaround to this would be to check whether current_is_async() and in
case it returns true just defer probing in an PROBE_FORCE_SYNCHRONOUS case. This
would at least be compatible with the guarantees given by
PROBE_FORCE_SYNCHRONOUS, but it doesn't sound quite right to me -- guess I have
to think about it a bit more.

In any case, given that this is not a supported case, this commit seems to be
wrong and should probably be reverted.

I think a quick workaround in the driver core as mentioned above is not a good
idea, instead this should be properly thought through.

It may not strictly be the fault of this patch - clearly 91703041697c 
("PCI: Allow built-in drivers to use async initial probing") is 
implicated in this too - but the fact is that it *has* exposed a bug 
that needs fixing one way or another, it can't just be left hanging and 
impacting end users.

At a side note, I think device_initial_probe() was not meant to be exposed
outside of the driver core in the first place. As the name suggests it is only
meant to be called on the initial probe() path (i.e. the initial probe() path of
the driver core). It seems to me that it ended up in include/linux/device.h
instead of drivers/base/base.h by accident.

The original commit - commit 765230b5f084 ("driver-core: add asynchronous
probing support for drivers") - introducing the feature even mentions "manual
binding is still synchronous" in its commit message and I think this has never
been changed.

So, it seems commit 91703041697c ("PCI: Allow built-in drivers to use async
initial probing") relies on something that might work by accident. :)

So, I wouldn't rule out any unexpected side effects entirely.