linux-kernel - [PATCH] block: remove non-existent partition dev_t return from blk_lookup

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-next>] [day] [month] [year] [list]

Message-Id: <20250403003532.412-1-chanho.min@lge.com>
Date: Thu,  3 Apr 2025 09:35:32 +0900
From: Chanho Min <chanho.min@....com>
To: Jens Axboe <axboe@...nel.dk>,
	linux-block@...r.kernel.org,
	linux-kernel@...r.kernel.org
Cc: Sven <dm-devel@...wermer.no>,
	Neil Brown <neilb@...e.de>,
	hch@....de,
	dm-devel@...ts.linux.dev,
	Gunho Lee <gunho.lee@....com>,
	Chanho Min <chanho.min@....com>
Subject: [PATCH] block: remove non-existent partition dev_t return from blk_lookup_devt

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@....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