Re: [PATCH] driver core: Add cmdline option to force probe type
From: Jianlin Lv
Date: Thu May 14 2026 - 11:14:29 EST
On Thu, May 14, 2026 at 9:49 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Thu, May 14, 2026 at 09:35:08PM +0800, Jianlin Lv wrote:
> > On Thu, May 14, 2026 at 6:16 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > On Thu, May 14, 2026 at 05:49:55PM +0800, Jianlin Lv wrote:
> > > > From: Jianlin Lv <iecedge@xxxxxxxxx>
> > > >
> > > > Device drivers that use asynchronous probing can cause non-deterministic
> > > > device ordering and naming across reboots. A typical example is storage
> > > > drivers (like sd/nvme): asynchronous probing can lead to inconsistent disk
> > > > logical names after reboot. In scenarios where disk naming consistency is
> > > > critical, the probe type should be set to synchronous.
> > > >
> > > > This patch introduces a driver_probe kernel parameter that overrides any
> > > > driver's hard-coded probe type settings and allows runtime control without
> > > > requiring kernel recompilation:
> > > >
> > > > driver_probe=PROBE_TYPE_SYNC,nvme,sd # Force specific drivers sync
> > > > driver_probe=PROBE_TYPE_ASYNC,*,usb # Force all async except usb
> > > > driver_probe=PROBE_TYPE_SYNC,* # Force all drivers synchronous
> > > >
> > > > The implementation replaces the limited driver_async_probe parameter with
> > > > a more flexible interface that can force either synchronous or asynchronous
> > > > probing as needed.
> > > >
> > > > Signed-off-by: Jianlin Lv <iecedge@xxxxxxxxx>
> > > > ---
> > > > .../admin-guide/kernel-parameters.txt | 27 +++++--
> > > > drivers/base/dd.c | 71 ++++++++++++++-----
> > > > 2 files changed, 74 insertions(+), 24 deletions(-)
> > > >
> > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > > > index 4d0f545fb3ec..b43a8bd20356 100644
> > > > --- a/Documentation/admin-guide/kernel-parameters.txt
> > > > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > > > @@ -1377,12 +1377,27 @@ Kernel parameters
> > > > it becomes active and is searched during signature
> > > > verification.
> > > >
> > > > - driver_async_probe= [KNL]
> > > > - List of driver names to be probed asynchronously. *
> > > > - matches with all driver names. If * is specified, the
> > > > - rest of the listed driver names are those that will NOT
> > > > - match the *.
> > > > - Format: <driver_name1>,<driver_name2>...
> > >
> > > You can not remove an existing user/kernel api, sorry, that is not
> > > allowed as you just broke all systems that were relying on this :(
> > >
> > Could you provide more suggestions on how to improve this patch?
>
> Not really, sorry, I don't think this is a change that should be done at
> all. disk naming is a long-solved issue, to think that you can fix that
> by doing sync/async device probing is not understanding both the issues
> involved, and how we solved it already :)
Do you mean referencing disks via by-path/by-id? In our production env
they can also be unstable; this is an example I encountered before:
https://lore.kernel.org/all/CAFA-uR_jk6jCmf9DTebSVBRwtoLuXuyvf1Biq+OObqRVAOZbBw@xxxxxxxxxxxxxx/
I understand that device naming in the kernel can change at any time. However,
Is it necessary to provide an interface that allows users to choose
the probe mode themselves?
Currently, driver_async_probe has lower priority than the drivers’
hard-coded probe_type settings.
Could we adjust the code as follows so that driver_async_probe has the
highest priority?
static bool driver_allows_async_probing(const struct device_driver *drv)
{
+ if (cmdline_requested_async_probing(drv->name))
+ return true;
+
switch (drv->probe_type) {
case PROBE_PREFER_ASYNCHRONOUS:
return true;
@@ -876,9 +879,6 @@ static bool driver_allows_async_probing(const
struct device_driver *drv)
return false;
default:
- if (cmdline_requested_async_probing(drv->name))
- return true;
-
if (module_requested_async_probing(drv->owner))
Jianlin
>
> Hint, never count on block device, or any device, names to be the same
> across reboots. That has NEVER been guaranteed on systems built in the
> past 20+ years.
>
> Please, just use the existing solutions, no new command line option
> should ever be needed here.
>
> thanks,
>
> greg k-h