On 18.09.20 17:25, Miklos Szeredi wrote:
> Pushed an updated version to fuse.git#submounts.
> 
> Also attached incremental patch (against rebase of
> virtiofs-submounts-v2 on fuse.git#for-next).
> 
> Changes:
> 
>  1) rebased on top of DAX patches
>  2) fixed CUSE
>  3) added locking for fc->mounts list
>  4) dissociate lifetime of fc from lifetime of root mount
>  5) do not hash mountpoint inodes
>  6) add FUSE_SUBMOUNTS init flag (replaces FUSE_ATTR_FLAGS but
> slightly different usage)
>  7) various cleanups
> 
> Note, the effect of 5 can only be observed if the same directory is
> bind mounted into multiple places:
> 
> HOST:
> cd /mnt
> mkdir 1 2
> mount --bind /dev/shm 1
> mount --bind /dev/shm 2
> 
> GUEST:
> mount -t virtiofs mnt /mnt
> cd /mnt/1
> ls ../2
> /bin/pwd
> 
> If the mountpoint is hashed, then the "ls ../2" will basically result
> in /mnt/1 inode being moved to /mnt/2, which is not what we want.  I
> don't think there's any negative side effect of the mountpoint being
> unhashed, but this is a bit subtle.
> 
> 
> On the server side, keying on just st_ino/st_dev is a really crude way
> of mapping out mounts.  Take this example:
> 
> HOST:
> cd /mnt
> mkdir 1
> mount --bind /dev/shm 1
> cd 1
> mkdir 2
> mount --bind /mnt 2
> ls /mnt/1/2/1
> 
> GUEST:
> mount -t virtiofs mnt /mnt
> ls /mnt/1/2/1
> 2
> ls /mnt/1/2/1/2/1/2/1/
> 2
> 
> So what we really need is keying on mount ID as well.
> 
> Attaching an incremental patch to do that.  Needs v5.8 kernel on host
> to actually make a difference, but commit fa2fcf4f1df1 ("statx: add
> mount ID") is trivial to backport to any kernel that has statx.
> 
> Please review and test.  If there are no major issues, this should be
> good to go for v5.10.

As for the virtiofsd patch, I wonder about:

> #if 0 && defined(HAVE_STATX) && STATX_MNT_ID

Shouldn’t the 0 not be there?  And should STATX_MNT_ID be wrapped in
defined()?

Furthermore I wonder why you have removed the parent_dev logic.  With
your patch, FUSE_ATTR_SUBMOUNT can be announced only by those functions
that invoke lo_do_lookup().  Is it OK to do so only there, and not every
time a fuse_attr is returned (be it as part of fuse_entry_out, as by
lo_link(), or directly by lo_getattr())?

(Also, the virtiofsd series will need a bit of an update with
FUSE_SUBMOUNTS replacing FUSE_ATTR_FLAGS.)

Max

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Virtio-fs mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virtio-fs

Reply via email to