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: <68f96adc63d_10e9100fc@dwillia2-mobl4.notmuch>
Date: Wed, 22 Oct 2025 16:38:04 -0700
From: <dan.j.williams@...el.com>
To: Michal Clapinski <mclapinski@...gle.com>, Dan Williams
	<dan.j.williams@...el.com>, Vishal Verma <vishal.l.verma@...el.com>, "Dave
 Jiang" <dave.jiang@...el.com>, <nvdimm@...ts.linux.dev>,
	<linux-cxl@...r.kernel.org>
CC: Pasha Tatashin <pasha.tatashin@...een.com>,
	<linux-kernel@...r.kernel.org>, Michal Clapinski <mclapinski@...gle.com>
Subject: Re: [PATCH 1/1] dax: add PROBE_PREFER_ASYNCHRONOUS to the pmem driver

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?

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