Re: [PATCH] fs,block: yield devices early

[Jan Kara <jack@suse.cz>]

On Wed 27-03-24 09:56:59, Christian Brauner wrote:
> On Tue, Mar 26, 2024 at 11:32:13PM +0100, Jan Kara wrote:
> > On Tue 26-03-24 13:47:22, Christian Brauner wrote:
> > > Currently a device is only really released once the umount returns to
> > > userspace due to how file closing works. That ultimately could cause
> > > an old umount assumption to be violated that concurrent umount and mount
> > > don't fail. So an exclusively held device with a temporary holder should
> > > be yielded before the filesystem is gone. Add a helper that allows
> > > callers to do that. This also allows us to remove the two holder ops
> > > that Linus wasn't excited about.
> > > 
> > > Fixes: f3a608827d1f ("bdev: open block device as files") # mainline only
> > > Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> > > Signed-off-by: Christian Brauner <brauner@kernel.org>
> > ...
> > > @@ -1012,6 +1005,29 @@ struct file *bdev_file_open_by_path(const char *path, blk_mode_t mode,
> > >  }
> > >  EXPORT_SYMBOL(bdev_file_open_by_path);
> > >  
> > > +static inline void bd_yield_claim(struct file *bdev_file)
> > > +{
> > > +	struct block_device *bdev = file_bdev(bdev_file);
> > > +	struct bdev_inode *bd_inode = BDEV_I(bdev_file->f_mapping->host);
> > > +	void *holder = bdev_file->private_data;
> > > +
> > > +	lockdep_assert_held(&bdev->bd_disk->open_mutex);
> > > +
> > > +	if (WARN_ON_ONCE(IS_ERR_OR_NULL(holder)))
> > > +		return;
> > > +
> > > +	if (holder != bd_inode) {
> > > +		bdev_yield_write_access(bdev_file);
> > 
> > Hum, what if we teached bdev_yield_write_access() about special bd_inode
> > holder and kept bdev_yield_write_access() and bd_yield_claim() separate as
> > they were before this patch? IMHO it would make code a bit more
> > understandable. Otherwise the patch looks good.
> 
> Ok, see appended patch where I folded in your suggestion.

Thanks. The patch looks good. Feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR