On Tue, Jun 6, 2023 at 1:23 PM Miklos Szeredi via fuse-devel <fuse-devel@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 19 May 2023 at 14:57, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > WIP > > > > Add an ioctl to associate a FUSE server open fd with a request. > > A later response to this request get use the FOPEN_PASSTHROUGH flag > > to request passthrough to the associated backing file. > > > > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> > > --- > > > > Miklos, > > > > After implementing refcounted backing files, I started to think how > > to limit the server from mapping too many files. > > > > I wanted to limit the backing files mappings to the number of open fuse > > files to simplify backing files accounting (i.e. open files are > > effectively accounted to clients). > > > > It occured to me that creatig a 1-to-1 mapping between fuse files and > > backing file ids is quite futile if there is no need to manage 1-to-many > > backing file mappings. > > > > If only 1-to-1 mapping is desired, the proposed ioctl associates a > > backing file with a pending request. The backing file will be kept > > open for as long the request lives, or until its refcount is handed > > over to the client, which can then use it to setup passthough to the > > backing file without the intermediate idr array. > > I think I understand what the patch does, but what I don't understand > is how this is going to solve the resource accounting problem. > > Can you elaborate? > It does not solve the resource accounting in the traditional way of limiting the number of open files to the resource limit of the server process. Instead, it has the similar effect of overlayfs pseudo files non accounting. A FUSE passthrough filesystem can contribute the same number of non accounted open fds as the number of FUSE fds accounted to different processes. A non privileged user can indirectly cause unaccounted open fds with a FUSE passthough fs in the exact same way that the same user can cause unaccounted open fds with an overlayfs mount if it can convince other users to open files on the FUSE/ovl that it has mounted. Am I making sense? One possible improvement to this API is to include the nodeid in FUSE_DEV_IOC_PASSTHROUGH_SETUP to make the mapping per-inode. If the mapping was already created during another open of the same inode, the setup would fail with a special error (EEXIST) so the caller would close the new backing fd, but the request already takes a reference to the backing fd of the inode, so FOPEN_PASSTHROUGH may proceed. On the last close, the backing fd refcount drops to zero and then is detached from the inode. A server that wants to manage the mapping lifetime can still use FUSE_DEV_IOC_PASSTHROUGH_OPEN/CLOSE to do so (with nodeid) argument. Thanks, Amir.
