From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (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 245112DC76A for ; Thu, 19 Mar 2026 08:48:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773910113; cv=none; b=OUsAIQpQgqoEGh+J5RzADhEl7IPU3cT3sZiahwEPndnutIMIr8YNTtnI/EJ8xCbRvDz180i6GBb9y0ZVrnr2i1enenoo/dYj8rMXYd1SSgI/EKvM0BBtXH6Y2cU9+9uKk3xKaP6bO55onZEnOUPfL1GVanjXwoIwRm0xep0dUOY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773910113; c=relaxed/simple; bh=04drrZazr9pwZk19Edvo1HCnMIqv9Cbt4O1of/HV45Q=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=c4qx0CP8J3FKv6o2OA5Ulgun8IqPHADYI6/ADfQVqwN/NfeA19cL3VVgk5L9jynoQH4NPiF+P7ivIPkzkOBiqxnw0U6akfZ0wKnekHLWto4ycc1BvOFOV8ZXHgk0fzwlfefTA/wlvrQc0DjBjTGkDYQNcciZ+CRp5Y7aF9YeN3s= 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=cAQjWx46; arc=none smtp.client-ip=209.85.221.49 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="cAQjWx46" Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-439d8df7620so260660f8f.0 for ; Thu, 19 Mar 2026 01:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773910110; x=1774514910; 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=yd/tafXGar8KLjaFL5qqMH0k5OVBqTpW3bKT/2gQAcY=; b=cAQjWx46so+ya0Q5gUdMn2Q0n9OES4tKH4TKNLDcZZG91oID5hywneLrQUSd+mDUJp AV7PsqKFATRln2YjbwqWah7LDSuPNaxK3Q6262MKogAe8U+qX9o8JwwbUxxcx6adBN9s Lp0xicGOeq+VrByLI+f3CUCKaC2lp2utZk9S0F61PyudH4HWi2pg3WvuYeU3phIepyy2 dWJpwb7e+P+9M3+BEoCq6WoVxWBRQ59TmaGao/2Fl5YkHmmlsA4hFdqKUYZV7QIgda8Q rIAiLa3pwIWFgwXfjm0F5Mmjc3pDFZsOqLz59htanj6PnPCrE6pYqBHpN6E6rvOW1EJn fhgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773910110; x=1774514910; 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=yd/tafXGar8KLjaFL5qqMH0k5OVBqTpW3bKT/2gQAcY=; b=qnAtoEhty5PMFv4zcT2k89pwVFwVriNiM4T2SBY/rPJqo3Gov1goJGaxk6kXyOIGpz SEMxTZmAf4IGJe04qlfSe1AL6DNNxU7pkTVPh4rLgiF3E+TrupspFdvq71Mj1MqND9lU W5YEZ1YMp0uCxOfugxPsOzQZcr0FNOVKpTfAkDh5gQr5tfQk16HJLPLBpFMJS7m19jio SwOgts5Qa+fkax5otxS8ZYRVSSPnVROlEFXD6NgVkdiEpzqchyuxh6dgztV4eUnEb/hx kLAXfb0MNSl0g/rEz2eg0HuuoooLInIsm4ig8nhoP17l1fz12ieEu+eBB/FQBWcZRsds CgWA== X-Forwarded-Encrypted: i=1; AJvYcCUQHgjiEJVdEnncF3Ne4XJ813fvOzieSK30bN5Md+ewKqKR/iWZ6uWvkBG3Hes0a1ZvMAgfQbV3FGaIPgs=@vger.kernel.org X-Gm-Message-State: AOJu0Yx/ScLG80R2Kfrs18BDHaeaS8zeWSmLCWRhtK+1VQQyPgQQDCJv oeupKOU+GBYOtDfgq3qNkfE7EYh0m5pm5VSzKRTnoNZ8NDbbsU4KrnMO X-Gm-Gg: ATEYQzzKRM0+AR5oBYphQiEmzLC/eqRsnWGJhqiIYorfAGk70o0mBdppJK8TyUxvlES y8MC7djhI+ZoSB/S56fM+NCko1I4tfkDRpnHwfdhJuIQKCcv4IFykbfijWSdilBkNHUT3iYdU6U CMAW2EG3x/SavfSvpain6RslzvcGlvz066URzcmn+YSL+wqWNQ1PvZG+kgZTMDdhL0PcGIhP4/f sVFmBjYQcsJbk5OQ10L5gZpEP/5G/7C6KJNdixqvuERJy05KBWvkTU66ih4iV2khvR3YrPmMJMQ OtOqEA4mCCAIgWJI7OGRuyNzwCQVtY8tycnBzdiqFVB45oIPGl1yuL8r6H3jCzNWiJq/oPWE/Ai ZiJKATGgcD2Bo5zIzaKByy5OulVX5Sv6dl5UV+Q5vLhUDm6Zv2GYhZmLUn/Po/hcFk8G5ZI/wPz j+pjOlYt5AphzMpMsQ5zPbv+ELYZRt X-Received: by 2002:a5d:5d13:0:b0:43b:3e40:222d with SMTP id ffacd0b85a97d-43b527a5382mr10940805f8f.19.1773910110188; Thu, 19 Mar 2026 01:48:30 -0700 (PDT) Received: from localhost ([2a01:cb16:3025:e833:3eb9:2e3d:e287:f728]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b518a3d78sm15773363f8f.34.2026.03.19.01.48.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Mar 2026 01:48:29 -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: Thu, 19 Mar 2026 09:47:47 +0100 Message-Id: Cc: "Alasdair Kergon" , "Mike Snitzer" , "Benjamin Marzinski" , , , , , Subject: Re: [PATCH] dm init: ensure device probing has finished in dm-mod.waitfor= From: "Guillaume Gonnet" To: "Peter Korsgaard" , "Mikulas Patocka" X-Mailer: aerc 0.20.1-8-g985ce7a92be4-dirty References: <20260317213229.18371-1-ggonnet.linux@gmail.com> <46a69472-84a8-c02b-1879-af30da13523c@redhat.com> <87y0jpf2ar.fsf@dell.be.48ers.dk> In-Reply-To: <87y0jpf2ar.fsf@dell.be.48ers.dk> Hello Peter, Here are my answers to your questions. > But how does it work? Ok I will try to give you more clues. The issue occurs when partitions scanning has not finished yet. That's my analysis but also the analysis from other people (see links I added in the PATCH comment). I will explain two cases: MMC and NVMe devices. For MMC devices: Here is the simplified call stack for partition scan: mmc_rescan() // delayed work mmc_add_card() device_add() driver_probe_device() // enter "probing" state mmc_blk_probe() add_disk_fwnode() While executing the mmc_blk_probe() function, the device is in probing state, ie. probe_count is non-zero. This function first creates the disk device then scans partitions with disk_scan_partitions(). Thus, waiting for probing to end is enough to fix the issue for MMC devices. For NVMe devices: Here is the simplified call stack for partition scan: nvme_scan_work() // delayed work nvme_scan_ns_async() // via async_schedule_domain() nvme_alloc_ns() device_add_disk() add_disk_fwnode() Here, NVMe device isn't in "probing" state but uses the asynchronous execution framework. Thus, you also have to synchronize all asynchronous function calls to make sure partition scan has finished, using async_synchronize_full() function. That's exactly what wait_for_device_probe() does: it waits for probing to b= e done and calls async_synchronize_full(). If you are still not convinced this does work, look at the wait_for_root() function. You will find these two actions in the code (probing wait and async_synchronize_full). I didn't find anyone complaining about this issue with rootwait=3D argument. > Do we still need the other wait_for_device_probe() call? Technically, I think it still works without the first call (if you move the second one out of the if block). But I preferred keeping it for the following two reaons: 1. That's what is done in rootwait=3D, which does not have the issue. I prefer copying what is working, especially when there is no problem keeping the first wait_for_device_probe() call. 2. Removing it may degrade boot performances for devices that the first wait_for_device_probe() actually waits for. In this case, wait is made by the while loop with its arbitrary 5ms sleep. When wait_for_device_probe() is kept, it only waits for the right amount of time and the while loop does not wait at all. > This looks nontrivial, a comment would be helpful. I think the commit message contains enough information to understand why the second wait_for_device_probe() call is required, a comment would contain less information so I prefer letting the code like that. Guillaume