linux-kernel - Re: [PATCH 1/1] dax: add PROBE_PREFER

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAi7L5eY898mdBLsW113c1VNdm9n+1rydT8WLLNJX86n8Q+zHQ@mail.gmail.com>
Date: Wed, 22 Oct 2025 16:53:52 -0700
From: Michał Cłapiński <mclapinski@...gle.com>
To: dan.j.williams@...el.com
Cc: Vishal Verma <vishal.l.verma@...el.com>, Dave Jiang <dave.jiang@...el.com>, 
	nvdimm@...ts.linux.dev, linux-cxl@...r.kernel.org, 
	Pasha Tatashin <pasha.tatashin@...een.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] dax: add PROBE_PREFER_ASYNCHRONOUS to the pmem driver

On Wed, Oct 22, 2025 at 4:38 PM <dan.j.williams@...el.com> wrote:
>
> Michal Clapinski wrote:
> > Comments in linux/device/driver.h say that the goal is to do async
> > probing on all devices. The current behavior unnecessarily slows down
> > the boot by synchronous probing dax_pmem devices, so let's change that.
> >
> > Signed-off-by: Michal Clapinski <mclapinski@...gle.com>
> > ---
> >  drivers/dax/pmem.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/dax/pmem.c b/drivers/dax/pmem.c
> > index bee93066a849..737654e8c5e8 100644
> > --- a/drivers/dax/pmem.c
> > +++ b/drivers/dax/pmem.c
> > @@ -77,6 +77,7 @@ static struct nd_device_driver dax_pmem_driver = {
> >       .probe = dax_pmem_probe,
> >       .drv = {
> >               .name = "dax_pmem",
> > +             .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> >       },
> >       .type = ND_DRIVER_DAX_PMEM,
> >  };
>
> Hi Michal,
>
> Apologies for not commenting earlier. When this first flew by I paused
> because libnvdimm predated some of the driver core work on asynchronous
> and has some local asynchronous registration.
>
> Can you say a bit more about how this patch in particular helps your
> case? For example, the pmem devices registered by memmap= (nd_e820
> driver), should end up in the nd_async_device_register() path.
>
> So even though the final attach is synchronous with device arrival, it
> should still be async with respect to other device probing.
>
> However, I believe that falls back to synchronous probing if the driver
> is loaded after the device has already arrived. Is that the case you are
> hitting?

Yes. I use all pmem/devdax modules built into the kernel so loading
them is in the critical path for kernel boot.
I use memmap= with devdax. So first, the pmem device is created
asynchronously, which means loading the nd_e820 module is always fast.
But then, the dax_pmem driver is loaded. If the dax device has not yet
been created by the async code, then loading this module is also fast.
But if the dax device has already been created, then attaching it to
the dax_pmem driver will be synchronous and on the critical boot path.

For thousands of dax devices, this increases the boot time by more
than a second. With the patch it takes ~10ms.

> I am ok with this in concept, but if we do this it should be done for
> all dax drivers, not just dax_pmem.

Will do in v2.