On Wed, Sep 30, 2020 at 05:44:54PM +0200, Miklos Szeredi wrote: > On Thu, Sep 24, 2020 at 3:13 PM Alessio Balsini <balsini@xxxxxxxxxxx> wrote: > > > > Introduce the new FUSE passthrough ioctl(), which allows userspace to > > specify a direct connection between a FUSE file and a lower file system > > file. > > Such ioctl() requires userspace to specify: > > - the file descriptor of one of its opened files, > > - the unique identifier of the FUSE request associated with a pending > > open/create operation, > > both encapsulated into a fuse_passthrough_out data structure. > > The ioctl() will search for the pending FUSE request matching the unique > > identifier, and update the passthrough file pointer of the request with the > > file pointer referenced by the passed file descriptor. > > When that pending FUSE request is handled, the passthrough file pointer > > is copied to the fuse_file data structure, so that the link between FUSE > > and lower file system is consolidated. > > How about returning an ID from the ioctl (like the fuse2 porototype) > and returning that in fuse_open_out.passthrough_fh? > > Seems a more straightforward interface to me. > > Thanks, > Miklos With this patch I tried to avoid any API modifications, for example, changing fuse_open_out, doing everything at ioctl() time, and limiting the allocation of dynamic memory. In my next patch set (that I'll share as soon as I have enough hours of testing with syzkaller) I implemented something similar to fuse2 in terms of communication between kernel and userspace, with an id passing as you recommended. So, userspace gets an id from the ioctl() and sends it back to the kernel through the open/create reply, setting the passthrough_fh field in fuse_open_out, that originally was the uint32_t padding. This wouldn't change the fuse_open_out struct size, but is kind of an API breakage. As in fuse2 I'm using IDR to generate the id and track the passthrough entry information. On the other hand, compared to fuse2, I have one dynamic IDR for each fuse_conn to prevent the owner of a connection from messing with the ids of others. In the upcoming patch set, the elements of each IDR serve the only purpose of keeping track of the id in the timespan between the ioctl() and the open/create reply. That IDR entry is removed right after the open/create request is completed. If in fuse2 the global IDR is queried for every read/write operation, my new patch set would still create a "passthrough entry" for each fuse_file to simplify the access to the lower file system at every read/write, getting rid of IDR searches for each read/write operation. Does this solution make sense? I'm not sure that the upcoming solution is simpler than this one, but for sure it keeps the interface more flexible and I like that it is moving in the direction of fuse2. Thanks, Alessio
