@@ -5,6 +5,7 @@
*/
#include <linux/blkdev.h>
#include <linux/ctype.h>
+#include <linux/major.h>
struct uuidcmp {
const char *uuid;
@@ -133,10 +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) {
+ if (partno < disk->minors && MAJOR(dev->devt) == MD_MAJOR) {
/* We need to return the right devno, even
- * if the partition doesn't exist yet.
+ * if the partition doesn't exist yet.(for MD devices)
*/
devt = MKDEV(MAJOR(dev->devt),
MINOR(dev->devt) + partno);
We have observed occasional failures in dm-init due to dm-mod.waitfor not working as expected when partitions are not yet ready. This issue was raised in a discussion on the mailing list: https://lore.kernel.org/all/e746b8b5-c04c-4982-b4bc-0fa240742755@schwermer.no/T/ but has remained unresolved since then. The root cause was identified in blk_lookup_devt(), which returns a dev_t even for non-existent partitions, a behavior introduced by commit 41b8c853a495 ("block: fix booting from partitioned md array"). This change was intended to support MD RAID devices, where partitions may not be available during early boot, allowing the system to proceed and detect them later. However, this behavior conflicts with cases like dm-init's waitfor mechanism, where an accurate dev_t for an existing partition is required. Returning a dev_t for non-existent partitions should be a special case (e.g., MD devices), while most scenarios, including Device Mapper, expect blk_lookup_devt() to reflect the actual partition state. To address this without major structural changes, this patch restricts the non-existent partition dev_t return to MD devices. For other devices, blk_lookup_devt() will only return a dev_t if the partition exists. With this change, dm-mod.waitfor works correctly, resolving the dm-init failures. Signed-off-by: Chanho Min <chanho.min@lge.com> --- block/early-lookup.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)