From: Christoph Hellwig <hch@lst.de>
To: Ming Lei <ming.lei@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>,
Christian Brauner <brauner@kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>, Jens Axboe <axboe@kernel.dk>,
Jan Kara <jack@suse.cz>, Denis Efremov <efremov@linux.com>,
linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 3/5] block: move bdev_mark_dead out of disk_check_media_change
Date: Wed, 18 Oct 2023 08:46:46 +0200 [thread overview]
Message-ID: <20231018064646.GA18710@lst.de> (raw)
In-Reply-To: <ZS9ODABLaRVcI5iy@fedora>
On Wed, Oct 18, 2023 at 11:16:28AM +0800, Ming Lei wrote:
> On Tue, Oct 17, 2023 at 08:48:21PM +0200, Christoph Hellwig wrote:
> > disk_check_media_change is mostly called from ->open where it makes
> > little sense to mark the file system on the device as dead, as we
> > are just opening it. So instead of calling bdev_mark_dead from
> > disk_check_media_change move it into the few callers that are not
> > in an open instance. This avoid calling into bdev_mark_dead and
> > thus taking s_umount with open_mutex held.
>
> ->open() is called when opening bdev every times, and there can be
> existed openers, so not sure if it makes little sense here.
Yes. It has to be a non-exclusive open, though, and how is that going
to help us with any general use case? If we really want to make the
media change notifications any useful we'd better just do the work
straight from the workqueue that polls for it.
next prev parent reply other threads:[~2023-10-18 6:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-17 18:48 don't take s_umount under open_mutex Christoph Hellwig
2023-10-17 18:48 ` [PATCH 1/5] block: simplify bdev_del_partition() Christoph Hellwig
2023-10-18 2:33 ` Ming Lei
2023-10-17 18:48 ` [PATCH 2/5] block: WARN_ON_ONCE() when we remove active partitions Christoph Hellwig
2023-10-18 2:36 ` Ming Lei
2023-10-19 8:31 ` Jan Kara
2023-10-17 18:48 ` [PATCH 3/5] block: move bdev_mark_dead out of disk_check_media_change Christoph Hellwig
2023-10-18 3:16 ` Ming Lei
2023-10-18 6:46 ` Christoph Hellwig [this message]
2023-10-18 9:15 ` Ming Lei
2023-10-18 12:10 ` Christoph Hellwig
2023-10-18 9:24 ` Christian Brauner
2023-10-19 5:57 ` Christoph Hellwig
2023-10-19 7:24 ` Christian Brauner
2023-10-19 8:34 ` Jan Kara
2023-10-17 18:48 ` [PATCH 4/5] block: assert that we're not holding open_mutex over blk_report_disk_dead Christoph Hellwig
2023-10-18 3:18 ` Ming Lei
2023-10-19 8:43 ` Jan Kara
2023-10-17 18:48 ` [PATCH 5/5] fs: assert that open_mutex isn't held over holder ops Christoph Hellwig
2023-10-18 9:53 ` Ming Lei
2023-10-19 8:43 ` Jan Kara
2023-10-19 9:35 ` don't take s_umount under open_mutex Christian Brauner
2023-10-19 11:27 ` 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=20231018064646.GA18710@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=efremov@linux.com \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).