public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Marzinski <bmarzins@redhat.com>
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,
	Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org
Subject: Re: [PATCH] dm init: ensure block device is ready before creating mapped device
Date: Sun, 8 Feb 2026 01:21:07 -0500	[thread overview]
Message-ID: <aYgrU8MpeTqJjTMl@redhat.com> (raw)
In-Reply-To: <20260206050526.930530-1-jaeyuel.im@lge.com>

On Fri, Feb 06, 2026 at 05:05:26AM +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()
> 
> Changes in v3:
> - Exported to a public header for both blkdev_get_no_open() and
>   blkdev_put_no_open()
> 
> Link: https://patchwork.kernel.org/project/dm-devel/patch/20251212000955.171808-1-jaeyuel.im@lge.com/
> Signed-off-by: jaeyuel.im <jaeyuel.im@lge.com>
> ---

You should put the description of your version changes here, after the
triple dash, so that they aren't part of the actual commit message. 

>  drivers/md/dm-init.c   | 14 ++++++++++++++
>  include/linux/blkdev.h |  3 +++
>  2 files changed, 17 insertions(+)
> 
> [snip] 
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 72e34acd439c..7f4a05b536ca 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -1873,4 +1873,7 @@ static inline int bio_split_rw_at(struct bio *bio,
>  
>  #define DEFINE_IO_COMP_BATCH(name)	struct io_comp_batch name = { }

If you're adding declarations linux/blkdev.h, you should remove them
from block/blk.h, so the functions aren't declared twice.

Also, IMHO it seems more natural for these declarions to placed near the
related bdev_file_open_by_dev() and bdev_file_open_by_path() ones
earlier in this file.

Finally I Added Jens and linux-block to the CCs, since the patch
includes changes to the block files. FYI, scripts/get_maintainer.pl can
help you send your patches the right people and lists.

-Ben
  
> +struct block_device *blkdev_get_no_open(dev_t dev, bool autoload);
> +void blkdev_put_no_open(struct block_device *bdev);
> +
>  #endif /* _LINUX_BLKDEV_H */
> -- 
> 2.34.1
> 


  reply	other threads:[~2026-02-08  6:21 UTC|newest]

Thread overview: 6+ 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
2026-02-06  5:05 ` [PATCH] " jaeyuel.im
2026-02-08  6:21   ` Benjamin Marzinski [this message]
  -- strict thread matches above, loose matches on Subject: below --
2025-12-11  7:34 jaeyuel.im
2025-12-11  8:19 ` Dongsheng Yang

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=aYgrU8MpeTqJjTMl@redhat.com \
    --to=bmarzins@redhat.com \
    --cc=agk@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=dm-devel@lists.linux.dev \
    --cc=jaeyuel.im@lge.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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