[PATCH] dm init: ensure device probing has finished in dm-mod.waitfor=

[PATCH] dm init: ensure device probing has finished in dm-mod.waitfor=

[Guillaume Gonnet]

The early_lookup_bdev() function returns successfully when the disk
device is present but not necessarily its partitions. In this situation,
dm_early_create() fails as the partition block device does not exist
yet.

In my case, this phenomenon occurs quite often because the device is
an SD card with slow reading times, on which kernel takes time to
enumerate available partitions.

Fortunately, the underlying device is back to "probing" state while
enumerating partitions. Waiting for all probing to end is enough to fix
this issue.

That's also the reason why this problem never occurs with rootwait=
parameter: the while loop inside wait_for_root() explicitly waits for
probing to be done and then the function calls async_synchronize_full().
These lines were omitted in 035641b, even though the commit says it's
based on the rootwait logic...

Anyway, calling wait_for_device_probe() after our while loop does the
job (it both waits for probing and calls async_synchronize_full).

Fixes: 035641b01e72 ("dm init: add dm-mod.waitfor to wait for asynchronously probed block devices")
Signed-off-by: Guillaume Gonnet <ggonnet.linux@gmail.com>
---

Hello,

This patch is my attempt to fix the dm-mod.waitfor= issue. I had this
fix for quite a while now, but I've never made the effort to contribute
until recently.

Some have tried to fix it this issue in the past but without finding
its real root cause (ie. not waiting for device probe to end).

Here are the links to those patches, for reference:
https://lore.kernel.org/all/b5c5cd56-b9dd-4368-a8e1-b9e0a07b79b4@schwermer.no/
https://lore.kernel.org/all/20250410080056.43247-1-chanho.min@lge.com/
https://lore.kernel.org/dm-devel/20251211073426.123026-1-jaeyuel.im@lge.com/

 drivers/md/dm-init.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/md/dm-init.c b/drivers/md/dm-init.c
index 7403823384c5..c1bacba92c65 100644
--- a/drivers/md/dm-init.c
+++ b/drivers/md/dm-init.c
@@ -303,8 +303,10 @@ static int __init dm_init_init(void)
 		}
 	}
 
-	if (waitfor[0])
+	if (waitfor[0]) {
+		wait_for_device_probe();
 		DMINFO("all devices available");
+	}
 
 	list_for_each_entry(dev, &devices, list) {
 		if (dm_early_create(&dev->dmi, dev->table,
-- 
2.43.0

Re: [PATCH] dm init: ensure device probing has finished in dm-mod.waitfor=

[Peter Korsgaard]

>>>>> "Guillaume" == Guillaume Gonnet <ggonnet.linux@gmail.com> writes:

Hello,

 > The early_lookup_bdev() function returns successfully when the disk
 > device is present but not necessarily its partitions. In this situation,
 > dm_early_create() fails as the partition block device does not exist
 > yet.

 > In my case, this phenomenon occurs quite often because the device is
 > an SD card with slow reading times, on which kernel takes time to
 > enumerate available partitions.

 > Fortunately, the underlying device is back to "probing" state while
 > enumerating partitions. Waiting for all probing to end is enough to fix
 > this issue.

 > That's also the reason why this problem never occurs with rootwait=
 > parameter: the while loop inside wait_for_root() explicitly waits for
 > probing to be done and then the function calls async_synchronize_full().
 > These lines were omitted in 035641b, even though the commit says it's
 > based on the rootwait logic...

 > Anyway, calling wait_for_device_probe() after our while loop does the
 > job (it both waits for probing and calls async_synchronize_full).

 > Fixes: 035641b01e72 ("dm init: add dm-mod.waitfor to wait for asynchronously probed block devices")
 > Signed-off-by: Guillaume Gonnet <ggonnet.linux@gmail.com>
 > ---

 > Hello,

 > This patch is my attempt to fix the dm-mod.waitfor= issue. I had this
 > fix for quite a while now, but I've never made the effort to contribute
 > until recently.

 > Some have tried to fix it this issue in the past but without finding
 > its real root cause (ie. not waiting for device probe to end).

Interesting, this is the first I hear about this (was not CC'ed on these
other patches).


 > Here are the links to those patches, for reference:
 > https://lore.kernel.org/all/b5c5cd56-b9dd-4368-a8e1-b9e0a07b79b4@schwermer.no/
 > https://lore.kernel.org/all/20250410080056.43247-1-chanho.min@lge.com/

I see that Christoph does not like the whole dm-mod.waitfor logic, but
this patch seems quite clear to me about what the issue is and how to
fix it.


 > diff --git a/drivers/md/dm-init.c b/drivers/md/dm-init.c
 > index 7403823384c5..c1bacba92c65 100644
 > --- a/drivers/md/dm-init.c
 > +++ b/drivers/md/dm-init.c
 > @@ -303,8 +303,10 @@ static int __init dm_init_init(void)
 >  		}
 >  	}
 
 > -	if (waitfor[0])
 > +	if (waitfor[0]) {
 > +		wait_for_device_probe();

There is already a wait_for_device_probe() just above the loop, so what
does this fix exactly? Do we need both?

Interesting enough, I have never encountered this issue myself. I do use
a partition identifier (dm-mod.waitfor="PARTLABEL=root-a") which
presumably sidetracks the /dev/mmcblk0 available, but partition table
not yet parsed issue.

-- 
Bye, Peter Korsgaard

Re: [PATCH] dm init: ensure device probing has finished in dm-mod.waitfor=

[Guillaume GONNET]

On Wed Mar 18, 2026 at 9:22 AM CET, Peter Korsgaard wrote:
> There is already a wait_for_device_probe() just above the loop, so what
> does this fix exactly? Do we need both?

The mmc_rescan() function (that probes the MMC device) is called in a
delayed work. When the issue occurs, MMC device has not started probing
yet (bacause the work has not been scheduled yet), so the first
wait_for_device_probe() does not wait for it. That's also the reason why
this waitfor parameter exists, otherwise the first wait_for_device_probe
would be enough to wait for the MMC device if probing wasn't deleayed.

The second call ensures that this delayed probing, which includes scaning
avaialble partitions, is done.

That's also what is done for rootwait=, there is a first call to
wait_for_device_probe() in prepare_namespace(), then the busy while loop
in wait_for_root() still wait for probing to be done.

> Interesting enough, I have never encountered this issue myself. I do use
> a partition identifier (dm-mod.waitfor="PARTLABEL=root-a") which
> presumably sidetracks the /dev/mmcblk0 available, but partition table
> not yet parsed issue.

Yes, the issue occurs only when partition scaning has not finished yet.

Re: [PATCH] dm init: ensure device probing has finished in dm-mod.waitfor=

[Mikulas Patocka]

Hi

I staged the patch, thanks.

Mikulas



On Tue, 17 Mar 2026, Guillaume Gonnet wrote:

> The early_lookup_bdev() function returns successfully when the disk
> device is present but not necessarily its partitions. In this situation,
> dm_early_create() fails as the partition block device does not exist
> yet.
> 
> In my case, this phenomenon occurs quite often because the device is
> an SD card with slow reading times, on which kernel takes time to
> enumerate available partitions.
> 
> Fortunately, the underlying device is back to "probing" state while
> enumerating partitions. Waiting for all probing to end is enough to fix
> this issue.
> 
> That's also the reason why this problem never occurs with rootwait=
> parameter: the while loop inside wait_for_root() explicitly waits for
> probing to be done and then the function calls async_synchronize_full().
> These lines were omitted in 035641b, even though the commit says it's
> based on the rootwait logic...
> 
> Anyway, calling wait_for_device_probe() after our while loop does the
> job (it both waits for probing and calls async_synchronize_full).
> 
> Fixes: 035641b01e72 ("dm init: add dm-mod.waitfor to wait for asynchronously probed block devices")
> Signed-off-by: Guillaume Gonnet <ggonnet.linux@gmail.com>
> ---
> 
> Hello,
> 
> This patch is my attempt to fix the dm-mod.waitfor= issue. I had this
> fix for quite a while now, but I've never made the effort to contribute
> until recently.
> 
> Some have tried to fix it this issue in the past but without finding
> its real root cause (ie. not waiting for device probe to end).
> 
> Here are the links to those patches, for reference:
> https://lore.kernel.org/all/b5c5cd56-b9dd-4368-a8e1-b9e0a07b79b4@schwermer.no/
> https://lore.kernel.org/all/20250410080056.43247-1-chanho.min@lge.com/
> https://lore.kernel.org/dm-devel/20251211073426.123026-1-jaeyuel.im@lge.com/
> 
>  drivers/md/dm-init.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/md/dm-init.c b/drivers/md/dm-init.c
> index 7403823384c5..c1bacba92c65 100644
> --- a/drivers/md/dm-init.c
> +++ b/drivers/md/dm-init.c
> @@ -303,8 +303,10 @@ static int __init dm_init_init(void)
>  		}
>  	}
>  
> -	if (waitfor[0])
> +	if (waitfor[0]) {
> +		wait_for_device_probe();
>  		DMINFO("all devices available");
> +	}
>  
>  	list_for_each_entry(dev, &devices, list) {
>  		if (dm_early_create(&dev->dmi, dev->table,
> -- 
> 2.43.0
> 

Re: [PATCH] dm init: ensure device probing has finished in dm-mod.waitfor=

[Peter Korsgaard]

>>>>> "Mikulas" == Mikulas Patocka <mpatocka@redhat.com> writes:

 > Hi
 > I staged the patch, thanks.

But how does it work? Do we still need the other wait_for_device_probe()
call? This looks nontrivial, a comment would be helpful.

-- 
Bye, Peter Korsgaard

Re: [PATCH] dm init: ensure device probing has finished in dm-mod.waitfor=

[Mikulas Patocka]

On Wed, 18 Mar 2026, Peter Korsgaard wrote:

> >>>>> "Mikulas" == Mikulas Patocka <mpatocka@redhat.com> writes:
> 
>  > Hi
>  > I staged the patch, thanks.
> 
> But how does it work? Do we still need the other wait_for_device_probe()
> call? This looks nontrivial, a comment would be helpful.
> 
> -- 
> Bye, Peter Korsgaard

So, if you want to add some comment to the code or to the patch header, 
let me know, and I will add it.

Mikulas

Re: [PATCH] dm init: ensure device probing has finished in dm-mod.waitfor=

[Guillaume Gonnet]

Hello Peter,
Here are my answers to your questions.

> But how does it work?

Ok I will try to give you more clues.

The issue occurs when partitions scanning has not finished yet. That's
my analysis but also the analysis from other people (see links I added
in the PATCH comment).

I will explain two cases: MMC and NVMe devices.

For MMC devices:

  Here is the simplified call stack for partition scan:

  mmc_rescan()  // delayed work
    mmc_add_card()
      device_add()
        driver_probe_device()  // enter "probing" state
          mmc_blk_probe()
            add_disk_fwnode()

  While executing the mmc_blk_probe() function, the device is in probing
  state, ie. probe_count is non-zero. This function first creates the
  disk device then scans partitions with disk_scan_partitions(). Thus,
  waiting for probing to end is enough to fix the issue for MMC devices.

For NVMe devices:

  Here is the simplified call stack for partition scan:

  nvme_scan_work()   // delayed work
    nvme_scan_ns_async()  // via async_schedule_domain()
      nvme_alloc_ns()
        device_add_disk()
          add_disk_fwnode()

  Here, NVMe device isn't in "probing" state but uses the asynchronous
  execution framework. Thus, you also have to synchronize all
  asynchronous function calls to make sure partition scan has finished,
  using async_synchronize_full() function.

That's exactly what wait_for_device_probe() does: it waits for probing to be
done and calls async_synchronize_full(). If you are still not convinced
this does work, look at the wait_for_root() function. You will find these
two actions in the code (probing wait and async_synchronize_full). I
didn't find anyone complaining about this issue with rootwait= argument.

> Do we still need the other wait_for_device_probe() call?

Technically, I think it still works without the first call (if you move
the second one out of the if block). But I preferred keeping it for the
following two reaons:

 1. That's what is done in rootwait=, which does not have the issue.
    I prefer copying what is working, especially when there is no problem
    keeping the first wait_for_device_probe() call.

 2. Removing it may degrade boot performances for devices that the first
    wait_for_device_probe() actually waits for. In this case, wait is
    made by the while loop with its arbitrary 5ms sleep. When
    wait_for_device_probe() is kept, it only waits for the right
    amount of time and the while loop does not wait at all.

> This looks nontrivial, a comment would be helpful.

I think the commit message contains enough information to understand why
the second wait_for_device_probe() call is required, a comment would
contain less information so I prefer letting the code like that.

Guillaume

Re: [PATCH] dm init: ensure device probing has finished in dm-mod.waitfor=

[Peter Korsgaard]

>>>>> "Guillaume" == Guillaume Gonnet <ggonnet.linux@gmail.com> writes:

 > Hello Peter,
 > Here are my answers to your questions.

Thanks for the details.

 >> This looks nontrivial, a comment would be helpful.

 > I think the commit message contains enough information to understand why
 > the second wait_for_device_probe() call is required, a comment would
 > contain less information so I prefer letting the code like that.

OK. Ideally the above description would have made it into the commit
message, but fine.

-- 
Bye, Peter Korsgaard

Re: [PATCH] dm init: ensure device probing has finished in dm-mod.waitfor=

[Francesco Valla]

Hello Guillaume,

On Tue, Mar 17, 2026 at 10:32:28PM +0100, Guillaume Gonnet wrote:
> The early_lookup_bdev() function returns successfully when the disk
> device is present but not necessarily its partitions. In this situation,
> dm_early_create() fails as the partition block device does not exist
> yet.
> 
> In my case, this phenomenon occurs quite often because the device is
> an SD card with slow reading times, on which kernel takes time to
> enumerate available partitions.
> 

I am now in the same situation, but I have seen the behavior also on
"fast" eMMC devices probing on slow single-core processors.

> Fortunately, the underlying device is back to "probing" state while
> enumerating partitions. Waiting for all probing to end is enough to fix
> this issue.
> 
> That's also the reason why this problem never occurs with rootwait=
> parameter: the while loop inside wait_for_root() explicitly waits for
> probing to be done and then the function calls async_synchronize_full().
> These lines were omitted in 035641b, even though the commit says it's
> based on the rootwait logic...
> 
> Anyway, calling wait_for_device_probe() after our while loop does the
> job (it both waits for probing and calls async_synchronize_full).
> 
> Fixes: 035641b01e72 ("dm init: add dm-mod.waitfor to wait for asynchronously probed block devices")
> Signed-off-by: Guillaume Gonnet <ggonnet.linux@gmail.com>
> ---
> 
> Hello,
> 
> This patch is my attempt to fix the dm-mod.waitfor= issue. I had this
> fix for quite a while now, but I've never made the effort to contribute
> until recently.
> 
> Some have tried to fix it this issue in the past but without finding
> its real root cause (ie. not waiting for device probe to end).
> 
> Here are the links to those patches, for reference:
> https://lore.kernel.org/all/b5c5cd56-b9dd-4368-a8e1-b9e0a07b79b4@schwermer.no/
> https://lore.kernel.org/all/20250410080056.43247-1-chanho.min@lge.com/
> https://lore.kernel.org/dm-devel/20251211073426.123026-1-jaeyuel.im@lge.com/
> 
>  drivers/md/dm-init.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/md/dm-init.c b/drivers/md/dm-init.c
> index 7403823384c5..c1bacba92c65 100644
> --- a/drivers/md/dm-init.c
> +++ b/drivers/md/dm-init.c
> @@ -303,8 +303,10 @@ static int __init dm_init_init(void)
>  		}
>  	}
>  
> -	if (waitfor[0])
> +	if (waitfor[0]) {
> +		wait_for_device_probe();
>  		DMINFO("all devices available");
> +	}
>  
>  	list_for_each_entry(dev, &devices, list) {
>  		if (dm_early_create(&dev->dmi, dev->table,
> -- 
> 2.43.0
>

Reviewed-by: Francesco Valla <francesco@valla.it>
Tested-by: Francesco Valla <francesco@valla.it>


Thank you!

Regards,
Francesco

Re: [PATCH] dm init: ensure device probing has finished in dm-mod.waitfor=

[Chanho Min]

On Thu, Mar 19, 2026 at 10:05:46AM +0100, Guillaume Gonnet wrote:
> Hello Chanho,
> 
> > This patch seems overly optimistic.
> > wait_for_device_probe() only waits for driver probe() callbacks to finish.
> > However, partition devices (e.g. /dev/mmcblk0p3) are often created
> > asynchronously after the parent disk probe has completed.
> 
> This patch does work and fix the issue. I let you read my detailed
> explanation on how it does in my latest message on the mailing list:
> https://lore.kernel.org/dm-devel/DH6MMYX3TX5Y.R3N3IX6370ED@gmail.com/
> 
> Basically, it replicates what was made for rootwait= argument, which has
> the same objectives but doesn't suffer from this issue.
Hi, Guillaume

I have verified that your patch does fix the issue I was seeing.
Given that blkdev_get_no_open() is no longer a public interface,
your approach seems to be the most suitable solution currently available.
Calling wait_for_device_probe() twice doesn't look particularly elegant,
but I can understand the reasoning behind it.

Reviewed-by: Chanho Min <chanho.min@lge.com>

Thanks
Chanho
> 
> > The previous per-device polling loop was much more robust for dm-verity rootfs
> > use cases without an initramfs. Replacing it with a single call to
> > wait_for_device_probe() is likely a regression.
> > Instead, we should restore (and possibly improve) proper per-device waiting
> > using blkdev_get_no_open() in a loop until the actual partition appears.
> >
> > That said, Christoph also pointed out in the thread that dm-init is inherently
> > fragile, and the proper long-term solution is to use initramfs + udev.
> 
> The blkdev_get_no_open() is an internal function of the block system.
> Christoph moved it out of public headers last year (see commit c632021).
> As you said, he is not a great fan of this dm-init wait mechanism so I'm
> pretty sure he won't let you make these functions public again. My patch
> does not depend of the block system at all, while still fixing the issue.
> 
> Guillaume