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/[email protected]/ > > 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 <[email protected]> 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
