Re: [PATCH] driver core: Add cmdline option to force probe type

[Jianlin Lv]

On Fri, May 15, 2026 at 2:13 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Thu, May 14, 2026 at 11:09:03PM +0800, Jianlin Lv wrote:
> > 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?
>
> No, use something that does not change, like filesystem labels or
> serial numbers, or something else that is guaranteed unique.
>
> > 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/
>
> Yes, paths can, and will, change.  Don't use them.
>
> Why not use a UUID, that is explicitly what those are designed for.

For cloud deployment, the local volume provisioner detects
and creates PVs for each local disk on the host, and it cleans up
the disks when they are released.
The local volume provisioner is deployed in the cluster as
DaemonSet.  For the same SKU, it uses a single, unified configuration
file to initialize local disks. In this scenario, UUIDs are not applicable.
In our case, logical names are used to identify the disk.

>
> > 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?
>
> It's not going to solve your problem, so I wouldn't worry about it.  And
> you can't remove it, although I really would like to :)

OK，Is the reason we can’t change the priority of driver_async_probe setting that
the original logic has changed, i.e. it would alter the original behavior?

Regards,
Jianlin
>
> thanks,
>
> greg k-h