public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: jaeyuel.im@lge.com
Cc: Alasdair Kergon <agk@redhat.com>,
	Mike Snitzer <snitzer@kernel.org>,
	Mikulas Patocka <mpatocka@redhat.com>,
	dm-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
	loth.son@lge.com
Subject: Re: [PATCH v2] dm init: ensure block device is ready before creating mapped device
Date: Sat, 3 Jan 2026 17:50:28 -0500	[thread overview]
Message-ID: <aVmdNKfUCaRXT1WN@laps> (raw)
In-Reply-To: <20251212000955.171808-1-jaeyuel.im@lge.com>

On Fri, Dec 12, 2025 at 12:09:55AM +0000, jaeyuel.im@lge.com wrote:
>From: "jaeyuel.im" <jaeyuel.im@lge.com>
>
>The current implementation of dm_init_init() uses early_lookup_bdev() to
>wait for the device node to appear. However, early_lookup_bdev() only
>verifies that the device node exists and returns the dev_t. It does not
>guarantee that the underlying block device structure is fully initialized
>and ready for I/O operations or to be opened.
>
>On certain platforms (e.g., embedded systems with specific storage
>drivers), this can lead to a race condition where dm_early_create()
>attempts to open the device immediately after early_lookup_bdev() returns,
>but fails because the device is not yet fully ready. This results in boot
>failures as the mapped device cannot be created.
>
>This patch adds an additional check using blkdev_get_no_open() after
>early_lookup_bdev() returns. This ensures that the struct block_device is
>actually available and the device is ready to be opened, effectively
>preventing the race condition.
>
>Changes in v2:
>- Pass autoload parameter for new blkdev_get_no_open()
>
>Signed-off-by: jaeyuel.im <jaeyuel.im@lge.com>
>---
> drivers/md/dm-init.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
>diff --git a/drivers/md/dm-init.c b/drivers/md/dm-init.c
>index b37bbe762500..b3905e094ffc 100644
>--- a/drivers/md/dm-init.c
>+++ b/drivers/md/dm-init.c
>@@ -296,10 +296,24 @@ static int __init dm_init_init(void)
> 	for (i = 0; i < ARRAY_SIZE(waitfor); i++) {
> 		if (waitfor[i]) {
> 			dev_t dev;
>+			struct block_device *bdev;
>
> 			DMINFO("waiting for device %s ...", waitfor[i]);
> 			while (early_lookup_bdev(waitfor[i], &dev))
> 				fsleep(5000);
>+
>+			/*
>+			 * early_lookup_bdev() only checks if the device node exists and
>+			 * returns the dev_t. It does not guarantee that the underlying
>+			 * block device is fully initialized and ready to be opened. On
>+			 * some platforms, this can lead to a race condition where
>+			 * dm_early_create() fails because the device is not yet ready.
>+			 * Ensure the block device is truly available by attempting to
>+			 * get it.
>+			 */
>+			while (!(bdev = blkdev_get_no_open(dev, false)))

This breaks the build when CONFIG_DM_INIT=y:

   drivers/md/dm-init.c:314:41: error: implicit declaration of function 'blkdev_get_no_open'; did you mean 'blkdev_get_zone_info'? [-Wimplicit-function-declaration]
     314 |                         while (!(bdev = blkdev_get_no_open(dev, false)))
   drivers/md/dm-init.c:316:25: error: implicit declaration of function 'blkdev_put_no_open' [-Wimplicit-function-declaration]
     316 |                         blkdev_put_no_open(bdev);

The problem is that blkdev_get_no_open() and blkdev_put_no_open() are declared
in block/blk.h, which is internal to the block layer and not accessible from
drivers/md/. These functions need to be exported to a public header, or
dm-init.c needs to use a different API.

-- 
Thanks,
Sasha

  reply	other threads:[~2026-01-03 22:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-12  0:09 [PATCH v2] dm init: ensure block device is ready before creating mapped device jaeyuel.im
2026-01-03 22:50 ` Sasha Levin [this message]
2026-02-06  5:05 ` [PATCH] " jaeyuel.im
2026-02-08  6:21   ` Benjamin Marzinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aVmdNKfUCaRXT1WN@laps \
    --to=sashal@kernel.org \
    --cc=agk@redhat.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=jaeyuel.im@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loth.son@lge.com \
    --cc=mpatocka@redhat.com \
    --cc=snitzer@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox