From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E77843AA1A4 for ; Wed, 18 Mar 2026 09:25:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773825925; cv=none; b=kuKQohitFSr4C2ETeDKo/oyFcpyknEpUpLuuiiy64ZQ0IfIpRPkfTcrJDD7ACAVeIMuWs4xDOeXb29PC1dPSXWLc6p7chdxFP1r+dCZBKFZ3R6Z/JWlDPBKW0JAIa5dfIhQmFyw40tZVwn7W2YIIYJerR3uXxgrCWu6GBUX8JQ4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773825925; c=relaxed/simple; bh=T/LVWvo2nvKPWMNK0xMWm2ZwaHkEiI/tDG+V+ayj/sk=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=pRtEI8JbeZ0839zJdGyHgcWXUI8YqtZRKsfQqdGa5FegetPbwWP3VVAEJmKjGwerl/GsFLQ8/hCfyF0s1R7KkqUKVPioFOuGJ1xLX3j3rOqrvy593/vXkQKUzspc/rcmC6YDVRBzDqCsdXOETFbn81vvgRPinyYE1UorOb9zoxg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Pt7TMhlS; arc=none smtp.client-ip=209.85.221.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Pt7TMhlS" Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-43b4915161fso2173272f8f.2 for ; Wed, 18 Mar 2026 02:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773825919; x=1774430719; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=T/LVWvo2nvKPWMNK0xMWm2ZwaHkEiI/tDG+V+ayj/sk=; b=Pt7TMhlSrrfEi0nYJIy6Cw3RLERU/xBaavsSoTulbwmJCr0XW+s/MTRGepnreyNxmN u5OUper5JfdMXbsGoZBrcuhuDsY5eQ1qOQ2p7cWuZHc40YCQuPoJVN9y/h5C7txMnbg2 VCQAuiNvFpZIoq0SYd1dqVn7rJHK5/OVs0sSlQWbQh4eNtMYdpUY+B5a1VhEfUjIdI4q WWn053fMJbZnTLYVUi/6NVmqw0ea7rFnUKK30GKjTFc9CD62r9a/b+/tFwt01bZCTI9A M736P5wXy0fMn2NqjS+/Qolzip8Y3INxXn1lusJDcjFKCJnMKw3p8ue5B2SSqhCBXCy/ 2DgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773825919; x=1774430719; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=T/LVWvo2nvKPWMNK0xMWm2ZwaHkEiI/tDG+V+ayj/sk=; b=KVqYo41xqSQZ8qi40AdWlYq6YwGEZw8PBKs9etP50fAgNtKpjqN7yyIfbmMJtGbRf+ f/kf1mHEuLvgVNMn6CnGlZfm+3yXDS1hhNqvpFH5O/LawjN06WO3Sp332LpS1sMxUlvZ wcGd2LFn9g2H4aS3Lyy9R8Iw8NM2S8ZJdtNcZpyY+16519y0kh0JCL5+ir78Ajw2TUJi OPCLGrbT+w2rgHJcUR19Q+pY9ClWxzh3T5nDc9eprk5VNEb4RaEkJxC+Y7fOz5Ya00lR hvcU94pyDkEDC6VM/zI33WiHNEg/SxxPsONlf/RTakQjOvxbUsqvROvNnwaf2Cs5pZgG XzHg== X-Forwarded-Encrypted: i=1; AJvYcCWQdTIU/C9CanTIV2B3yYG7txeMhVfESfddgmPeMFwr6DY02boKwV2QX86Ih6tIQEaT8ZPNEPbSitX8OaI=@vger.kernel.org X-Gm-Message-State: AOJu0Yx/9hA9vCqjI4dt8rFFc+cU3LqRBNt5xIMpyYtcfRMDY43p17Sz mR8Sug7iHrQCE/YEiC7HknKbBYAvXyyau5yI0e6oZK1oLqfDZUN2Vewg X-Gm-Gg: ATEYQzw9ACAb5JXDVJsx+99OlBSGAbc8iOj4P2A3fOuxnyQeRslhXojSrZwv+xgcgTB ynAhHDdNBbYliecNerxhiXqP7XN4Nv8JxjKmcwGdTFIxE/+XtrrHiJIw3S7K+YB4aM8eyEJw9Ne VOav3/rGUjvIel0PdoYnkrGaBdyr0CrXRu38x6559qnp2/fagNF4knrcIvV1CbuqVQa6kXrDD5M DEIrV5Oxcrn+0ovjZjlfQHZG+7Vgt3KxBW1+48jJIFx12f1V05HBnk2yQUVKBWf2hd9AuGW50E7 EJPC5dBQ/BCr1kKgHovCDwcpgZ4bRziRGMbECvj0rmQ5JeVqgXlI911aBruL4hptaTE1M0xOF0N UNHPAIhD9RXTxec3KZ8Y1zjOuXtGWDWx1ngSJKPVRZHdr1DvLosZwsjSpucPbyUCLpEuxHtOPVZ QMuSfsOmv4ML4R7SLMw8Jal6t12sOd X-Received: by 2002:a05:6000:24c3:b0:43b:3d02:7806 with SMTP id ffacd0b85a97d-43b527c4e07mr4024003f8f.28.1773825918743; Wed, 18 Mar 2026 02:25:18 -0700 (PDT) Received: from localhost ([2a01:cb16:3041:ebff:ef18:4b18:1931:7603]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b51892234sm6249342f8f.24.2026.03.18.02.25.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Mar 2026 02:25:18 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 18 Mar 2026 10:25:15 +0100 Message-Id: Cc: "Alasdair Kergon" , "Mike Snitzer" , "Mikulas Patocka" , "Benjamin Marzinski" , , , , , , Subject: Re: [PATCH] dm init: ensure device probing has finished in dm-mod.waitfor= From: "Guillaume GONNET" To: "Peter Korsgaard" X-Mailer: aerc 0.20.1-8-g985ce7a92be4-dirty References: <20260317213229.18371-1-ggonnet.linux@gmail.com> <87341xh7hc.fsf@dell.be.48ers.dk> In-Reply-To: <87341xh7hc.fsf@dell.be.48ers.dk> 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=3D, 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=3D"PARTLABEL=3Droot-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.