Re: [PATCH 6/6] fs: Make bind mounts work with bdev_allow_write_mounted=n

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri 07-07-23 09:39:05, Christian Brauner wrote:
> On Thu, Jul 06, 2023 at 06:12:55PM +0200, Jan Kara wrote:
> > On Thu 06-07-23 08:55:18, Christoph Hellwig wrote:
> > > On Tue, Jul 04, 2023 at 02:56:54PM +0200, Jan Kara wrote:
> > > > When we don't allow opening of mounted block devices for writing, bind
> > > > mounting is broken because the bind mount tries to open the block device
> > > > before finding the superblock for it already exists. Reorganize the
> > > > mounting code to first look whether the superblock for a particular
> > > > device is already mounted and open the block device only if it is not.
> > > 
> > > Warning: this might be a rathole.
> > > 
> > > I really hate how mount_bdev / get_tree_bdev try to deal with multiple
> > > mounts.
> > > 
> > > The idea to just open the device and work from there just feels very
> > > bogus.
> > > 
> > > There is really no good reason to have the bdev to find a superblock,
> > > the dev_t does just fine (and in fact I have a patch to remove
> > > the bdev based get_super and just use the dev_t based one all the
> > > time).  So I'd really like to actually turn this around and only
> > > open when we need to allocate a new super block.  That probably
> > > means tearning sget_fc apart a bit, so it will turn into a fair
> > > amount of work, but I think it's the right thing to do.
> > 
> > Well, this is exactly what this patch does - we use dev_t to lookup the
> > superblock in sget_fc() and we open the block device only if we cannot find
> > matching superblock and need to create a new one...
> 
> Can you do this rework independent of the bdev_handle work that you're
> doing so this series doesn't depend on the other work and we can get
> the VFS bits merged for this?

Yeah, it should be doable. I'll have a look into it.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux