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

[Greg KH]

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.

> 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 :)

thanks,

greg k-h