On Fri, 21 May 2021 14:37:25 +0200
Miklos Szeredi [off-list ref] wrote:
On Fri, 21 May 2021 at 12:06, Greg Kurz [off-list ref] wrote:
quoted
On Fri, 21 May 2021 10:50:34 +0200
Miklos Szeredi [off-list ref] wrote:
quoted
On Fri, 21 May 2021 at 10:39, Greg Kurz [off-list ref] wrote:
quoted
On Fri, 21 May 2021 10:26:27 +0200
Miklos Szeredi [off-list ref] wrote:
quoted
On Thu, 20 May 2021 at 17:47, Greg Kurz [off-list ref] wrote:
quoted
All submounts share the same virtio-fs device instance as the root
mount. If the same virtiofs filesystem is mounted again, sget_fc()
is likely to pick up any of these submounts and reuse it instead of
the root mount.
On the server side:
# mkdir ${some_dir}
# mkdir ${some_dir}/mnt1
# mount -t tmpfs none ${some_dir}/mnt1
# touch ${some_dir}/mnt1/THIS_IS_MNT1
# mkdir ${some_dir}/mnt2
# mount -t tmpfs none ${some_dir}/mnt2
# touch ${some_dir}/mnt2/THIS_IS_MNT2
On the client side:
# mkdir /mnt/virtiofs1
# mount -t virtiofs myfs /mnt/virtiofs1
# ls /mnt/virtiofs1
mnt1 mnt2
# grep virtiofs /proc/mounts
myfs /mnt/virtiofs1 virtiofs rw,seclabel,relatime 0 0
none on /mnt/mnt1 type virtiofs (rw,relatime,seclabel)
none on /mnt/mnt2 type virtiofs (rw,relatime,seclabel)
And now remount it again:
# mount -t virtiofs myfs /mnt/virtiofs2
# grep virtiofs /proc/mounts
myfs /mnt/virtiofs1 virtiofs rw,seclabel,relatime 0 0
none on /mnt/mnt1 type virtiofs (rw,relatime,seclabel)
none on /mnt/mnt2 type virtiofs (rw,relatime,seclabel)
myfs /mnt/virtiofs2 virtiofs rw,seclabel,relatime 0 0
# ls /mnt/virtiofs2
THIS_IS_MNT2
Submount mnt2 was picked-up instead of the root mount.
quoted
Why is this a problem?
It seems very weird to mount the same filesystem again
and to end up in one of its submounts. We should have:
# ls /mnt/virtiofs2
mnt1 mnt2
Okay, sorry, I understand the problem. The solution is wrong,
however: the position of the submount on that list is no indication
that it's the right one (it's possible that the root sb will go away
and only a sub-sb will remain).
Ah... I had myself convinced this could not happen, i.e. you can't
unmount a parent sb with a sub-sb still mounted.
No, but it's possible for sub-sb to continue existing after it's no
longer a submount of original mount.
quoted
How can this happen ?
E.g. move the submount out of the way, then unmount the parent, or
detach submount (umount -l) while keeping something open in there and
umount the parent.
Ok, I get it now. Thanks for the clarification.
quoted
quoted
Even just setting a flag in the root, indicating that it's the root
isn't fully going to solve the problem.
Here's issue in full:
case 1: no connection for "myfs" exists
- need to create fuse_conn, sb
case 2: connection for "myfs" exists but only sb for submount
How would we know this sb isn't a root sb ?
quoted
- only create sb for root, reuse fuse_conn
case 3: connection for "myfs" as well as root sb exists
- reuse sb
I'll think about how to fix this properly, it's probably going to be
rather more involved...
Sure. BTW I'm wondering why we never reuse sbs for submounts ?
Right, same general issue.
An sb can be identified by its root nodeid, so I guess the proper fix
to make the root nodeid be the key for virtio_fs_test_super().
Cool, I was thinking about doing this exactly. :)
Thanks,
Miklos
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization