[PATCH] block: remove non-existent partition dev_t return from blk_lookup_devt

[PATCH] block: remove non-existent partition dev_t return from blk_lookup_devt

[Chanho Min]

We encountered frequent boot failures while setting up a dm-verity rootfs with
the following configuration, and found that this issue had been reported
previously:

  root=/dev/dm-0
  dm-mod.waitfor=/dev/mmcblk0p23

The error observed was:

  device-mapper: table: 254:0: verity: Data device lookup failed (-ENXIO)
  device-mapper: ioctl: error adding target to table

Bisecting the issue revealed that this was a latent problem exacerbated by
commit 238d991f054a ("dm: use fsleep() instead of msleep() for deterministic
sleep duration"), after which the failures became more frequent. Further
investigation pinpointed the root cause to a special case added in
blk_lookup_devt() by commit 41b8c853a495 ("block: fix booting from partitioned
md array")

This commit modified blk_lookup_devt() to return a dev_t for non-existent
partitions to support MD RAID booting when partitions are not yet available,
e.g., for root=/dev/md_d0p1. While this addressed the MD issue, it deviates
from the expected role of blk_lookup_devt(), which should return a dev_t only
for existing block devices. Adding MD-specific logic to a common block layer
function was a suboptimal approach, as it compromises the function's clarity
and causes side effects, such as the dm-init failures seen with dm-verity.

The MD RAID booting issue should ideally have been handled within the MD
driver or boot logic (e.g., via a dedicated md_lookup_devt() function) rather
than modifying a generic lookup function. This patch removes the non-existent
partition dev_t return logic, restoring blk_lookup_devt() to its intended
purpose. This resolves the dm-verity boot failures by ensuring accurate dev_t
returns.

If MD RAID booting still depends on this behavior in some setups, a regression
may occur. In that case, the MD subsystem should implement a proper solution
(e.g., specific lookup function) rather than relying on this workaround.
Testers are encouraged to verify MD RAID booting with partitioned root devices
(e.g., root=/dev/md_d0p1) to confirm.

Signed-off-by: Chanho Min <chanho.min@lge.com>
---
 block/early-lookup.c | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/block/early-lookup.c b/block/early-lookup.c
index 3fb57f7d2b127..3764dfb429c54 100644
--- a/block/early-lookup.c
+++ b/block/early-lookup.c
@@ -134,17 +134,9 @@ static dev_t __init blk_lookup_devt(const char *name, int partno)
 		if (strcmp(dev_name(dev), name))
 			continue;
 
-		if (partno < disk->minors) {
-			/* We need to return the right devno, even
-			 * if the partition doesn't exist yet.
-			 */
-			devt = MKDEV(MAJOR(dev->devt),
-				     MINOR(dev->devt) + partno);
-		} else {
-			devt = part_devt(disk, partno);
-			if (devt)
-				break;
-		}
+		devt = part_devt(disk, partno);
+		if (devt)
+			break;
 	}
 	class_dev_iter_exit(&iter);
 	return devt;
-- 
2.17.1

Re: [PATCH] block: remove non-existent partition dev_t return from blk_lookup_devt

[Christoph Hellwig]

NAK.

Don't do this.  Md at least has a reason for doing this silly things
as in the code as written in the 1990s where people did not know better.

The dm-initwait code has no such excuse as it was written recently and
explicitly ignored the rules to not use this early dev_t lookup code that
is known to be broken.  You now have to live with the fallout because you
decided to you this broken code.  Stop using it if you care.

If there's one thing we need to do is to warn everyone in the Kconfig
and boot time dmesg that dm-initwait is broken.