[Virtio-fs] [virtiofsd-rs] MR opened: File handle follow-up patches

[virtiofs-bot at sinrega.org]

Hi,

While we have merged file handle support in virtiofsd-rs a while ago, the C version of the patches has gone through some iterations (currently at v4).  This merge request contains patches to bring the relevant changes to virtiofsd-rs that have been requested during the iterations’ reviews.

They are the following:
1. Clarification and fix for the inode lookup fallback filter: When we cannot find an inode by file handle, we fall back to looking it up by its inode ID.  The condition for this was partially wrong, and the explanation kind of backwards.  Clarify the explanation, and fix the condition.
2. Creating a file handle returns a mount ID for which this handle is
valid; opening it requires an FD for the given mount.  Right now, to
get this FD, we simply open the first inode we look up on the
respective mount.  However, we want to open the moint point instead. 
(In practice, the mount point is probably always going to be the first
inode we look up, but it’s better to make this explicit.)  This has
to do with the projected addition of inotify support: The guest should
get a notification when some inode is deleted.  While we have a mount
FD open, the respective inode cannot really be deleted.  There are two
reasons why we should thus choose mount points for the mount FDs:
First, to delete a mount point, everything on the mount must be deleted
first, so there can be no open file handles before the moint point can
be deleted.  Refcounting mount FDs will then ensure that the mount FD
is closed before the guest can attempt to delete the mount point. 
Second, host mount points cannot be deleted anyway, so they play no
role when it comes to deletion notifications.
3. As brought up in the last point, we want to refcount mount FDs.  Deletion notifications are not really the practical reason for this, because, as explained, mount points cannot be deleted anyway.  However, we still want to close mount FDs when they are no longer needed.  For example, this means that when the guest tells the host to forget about an entire submount, the host can unmount it.

I’m not sure in practice we really need anything but the first patch (point number 1), but I think the end result is a bit cleaner than what we have right now, so I think these patches are worth it even if they have little impact in practice.
---
https://gitlab.com/virtio-fs/virtiofsd-rs/-/merge_requests/41