From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Gao Xiang <hsiangkao@linux.alibaba.com>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
Jan Kara <jack@suse.cz>, Christian Brauner <brauner@kernel.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jason Wang <jasowang@redhat.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Luis Chamberlain <mcgrof@kernel.org>,
linux-block@vger.kernel.org,
Joseph Qi <joseph.qi@linux.alibaba.com>,
guanghuifeng@linux.alibaba.com, zongyong.wzy@alibaba-inc.com,
zyfjeff@linux.alibaba.com,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: question about bd_inode hashing against device_add() // Re: [PATCH 03/11] block: call bdev_add later in device_add_disk
Date: Fri, 31 Oct 2025 15:34:09 +0100 [thread overview]
Message-ID: <2025103106-proposal-jogging-a076@gregkh> (raw)
In-Reply-To: <ec8b1c76-c211-49a5-a056-6a147faddd3b@linux.alibaba.com>
On Fri, Oct 31, 2025 at 08:23:32PM +0800, Gao Xiang wrote:
>
>
> On 2025/10/31 18:12, Gao Xiang wrote:
> > Hi Greg,
> >
> > On 2025/10/31 17:58, Greg Kroah-Hartman wrote:
> > > On Fri, Oct 31, 2025 at 05:54:10PM +0800, Gao Xiang wrote:
> > > >
> > > >
> > > > On 2025/10/31 17:45, Christoph Hellwig wrote:
>
> ...
>
> > > > > But why does the device node
> > > > > get created earlier? My assumption was that it would only be
> > > > > created by the KOBJ_ADD uevent. Adding the device model maintainers
> > > > > as my little dig through the core drivers/base/ code doesn't find
> > > > > anything to the contrary, but maybe I don't fully understand it.
> > > >
> > > > AFAIK, device_add() is used to trigger devtmpfs file
> > > > creation, and it can be observed if frequently
> > > > hotpluging device in the VM and mount. Currently
> > > > I don't have time slot to build an easy reproducer,
> > > > but I think it's a real issue anyway.
> > >
> > > As I say above, that's not normal, and you have to be root to do this,
> I just spent time to reproduce with dynamic loop devices and
> actually it's easy if msleep() is located artificiallly,
> the diff as below:
>
> diff --git a/block/bdev.c b/block/bdev.c
> index 810707cca970..a4273b5ad456 100644
> --- a/block/bdev.c
> +++ b/block/bdev.c
> @@ -821,7 +821,7 @@ struct block_device *blkdev_get_no_open(dev_t dev, bool autoload)
> struct inode *inode;
>
> inode = ilookup(blockdev_superblock, dev);
> - if (!inode && autoload && IS_ENABLED(CONFIG_BLOCK_LEGACY_AUTOLOAD)) {
> + if (0) {
> blk_request_module(dev);
> inode = ilookup(blockdev_superblock, dev);
> if (inode)
> diff --git a/block/genhd.c b/block/genhd.c
> index 9bbc38d12792..3c9116fdc1ce 100644
> --- a/block/genhd.c
> +++ b/block/genhd.c
> @@ -428,6 +428,8 @@ static void add_disk_final(struct gendisk *disk)
> set_bit(GD_ADDED, &disk->state);
> }
>
> +#include <linux/delay.h>
> +
> static int __add_disk(struct device *parent, struct gendisk *disk,
> const struct attribute_group **groups,
> struct fwnode_handle *fwnode)
> @@ -497,6 +499,9 @@ static int __add_disk(struct device *parent, struct gendisk *disk,
> if (ret)
> goto out_free_ext_minor;
>
> + if (disk->major == LOOP_MAJOR)
> + msleep(2500); // delay 2.5s for all loops
> +
Yes, so you need to watch for the uevent to happen, THEN it is safe to
access the block device. Doing it before then isn't a good idea :)
But, if you think this is an issue, do you have a patch that passes your
testing to fix it?
thanks,
greg k-h
next prev parent reply other threads:[~2025-10-31 14:34 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-18 14:45 add error handling to add_disk / device_add_disk Christoph Hellwig
2021-08-18 14:45 ` [PATCH 01/11] block: add a sanity check for a live disk in del_gendisk Christoph Hellwig
2021-08-19 10:41 ` Hannes Reinecke
2021-08-18 14:45 ` [PATCH 02/11] block: fold register_disk into device_add_disk Christoph Hellwig
2021-08-19 10:48 ` Hannes Reinecke
2021-08-18 14:45 ` [PATCH 03/11] block: call bdev_add later in device_add_disk Christoph Hellwig
2021-08-20 6:06 ` Hannes Reinecke
2025-10-31 7:46 ` question about bd_inode hashing against device_add() // " Gao Xiang
2025-10-31 9:09 ` Christoph Hellwig
2025-10-31 9:36 ` Gao Xiang
2025-10-31 9:45 ` Christoph Hellwig
2025-10-31 9:54 ` Gao Xiang
2025-10-31 9:58 ` Greg Kroah-Hartman
2025-10-31 10:12 ` Gao Xiang
2025-10-31 12:23 ` Gao Xiang
2025-10-31 12:25 ` Gao Xiang
2025-10-31 14:34 ` Greg Kroah-Hartman [this message]
2025-10-31 14:44 ` Gao Xiang
2025-11-05 3:04 ` Gao Xiang
2025-11-05 12:30 ` Christian Brauner
2025-11-05 14:13 ` Gao Xiang
2025-10-31 14:31 ` Greg Kroah-Hartman
2025-10-31 14:40 ` Gao Xiang
2021-08-18 14:45 ` [PATCH 04/11] block: create the bdi link earlier " Christoph Hellwig
2021-08-20 6:08 ` Hannes Reinecke
2021-08-18 14:45 ` [PATCH 05/11] block: call blk_integrity_add " Christoph Hellwig
2021-08-20 6:08 ` Hannes Reinecke
2021-08-18 14:45 ` [PATCH 06/11] block: call blk_register_queue " Christoph Hellwig
2021-08-20 6:09 ` Hannes Reinecke
2021-08-18 14:45 ` [PATCH 07/11] block: return errors from blk_integrity_add Christoph Hellwig
2021-08-20 6:10 ` Hannes Reinecke
2021-08-18 14:45 ` [PATCH 08/11] block: return errors from disk_alloc_events Christoph Hellwig
2021-08-20 6:10 ` Hannes Reinecke
2021-08-18 14:45 ` [PATCH 09/11] block: add error handling for device_add_disk / add_disk Christoph Hellwig
2021-08-20 6:12 ` Hannes Reinecke
2021-08-18 14:45 ` [PATCH 10/11] virtio_blk: add error handling support for add_disk() Christoph Hellwig
2021-08-20 6:12 ` Hannes Reinecke
2021-08-18 14:45 ` [PATCH 11/11] null_blk: " Christoph Hellwig
2021-08-20 6:13 ` Hannes Reinecke
2021-08-23 18:57 ` add error handling to add_disk / device_add_disk Jens Axboe
2021-08-23 19:44 ` Luis Chamberlain
2021-08-23 19:50 ` Jens Axboe
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=2025103106-proposal-jogging-a076@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=dakr@kernel.org \
--cc=guanghuifeng@linux.alibaba.com \
--cc=hch@lst.de \
--cc=hsiangkao@linux.alibaba.com \
--cc=jack@suse.cz \
--cc=jasowang@redhat.com \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mcgrof@kernel.org \
--cc=mst@redhat.com \
--cc=rafael@kernel.org \
--cc=zongyong.wzy@alibaba-inc.com \
--cc=zyfjeff@linux.alibaba.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.