On 23.09.20 19:15, Miklos Szeredi wrote: > On Wed, Sep 23, 2020 at 5:45 PM Max Reitz <[email protected]> wrote: >> >> 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()? > > Right, that was left there from testing. > >> 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())? > > No, object creation never results in a mounted object. If the newly > created object is mounted on at a later time, the revalidate logic > will take care of that.
So lo_getattr() is not an issue either, because all mount operations will be handled by the revalidate logic? Max
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Virtio-fs mailing list [email protected] https://www.redhat.com/mailman/listinfo/virtio-fs
