[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230805161904.GM11377@frogsfrogsfrogs>
Date: Sat, 5 Aug 2023 09:19:04 -0700
From: "Darrick J. Wong" <djwong@...nel.org>
To: Christoph Hellwig <hch@....de>
Cc: Al Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>,
Jan Kara <jack@...e.cz>, Chris Mason <clm@...com>,
Josef Bacik <josef@...icpanda.com>,
David Sterba <dsterba@...e.com>, Theodore Ts'o <tytso@....edu>,
Andreas Dilger <adilger.kernel@...ger.ca>,
Jaegeuk Kim <jaegeuk@...nel.org>, Chao Yu <chao@...nel.org>,
Ryusuke Konishi <konishi.ryusuke@...il.com>,
Jens Axboe <axboe@...nel.dk>, linux-btrfs@...r.kernel.org,
linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
linux-nilfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-xfs@...r.kernel.org, linux-block@...r.kernel.org
Subject: Re: [PATCH 11/12] xfs: drop s_umount over opening the log and RT
devices
On Sat, Aug 05, 2023 at 10:32:39AM +0200, Christoph Hellwig wrote:
> On Wed, Aug 02, 2023 at 09:32:19AM -0700, Darrick J. Wong wrote:
> > > + /* see get_tree_bdev why this is needed and safe */
> >
> > Which part of get_tree_bdev? Is it this?
> >
> > /*
> > * s_umount nests inside open_mutex during
> > * __invalidate_device(). blkdev_put() acquires
> > * open_mutex and can't be called under s_umount. Drop
> > * s_umount temporarily. This is safe as we're
> > * holding an active reference.
> > */
> > up_write(&s->s_umount);
> > blkdev_put(bdev, fc->fs_type);
> > down_write(&s->s_umount);
>
> Yes. With the refactoring earlier in the series get_tree_bdev should
> be trivial enough to not need a more specific reference. If you
> think there's a better way to refer to it I can update the comment,
> though.
How about:
/*
* blkdev_put can't be called under s_umount, see the comment in
* get_tree_bdev for more details
*/
with that and the label name change,
Reviewed-by: Darrick J. Wong <djwong@...nel.org>
--D
> > > mp->m_logdev_targp = mp->m_ddev_targp;
> > > }
> > >
> > > - return 0;
> > > + error = 0;
> > > +out_unlock:
> > > + down_write(&sb->s_umount);
> >
> > Isn't down_write taking s_umount? I think the label should be
> > out_relock or something less misleading.
>
> Agreed. Christian, can you just change this in your branch, or should
> I send an incremental patch?
>
Powered by blists - more mailing lists