On Fri, Sep 22, 2023 at 3:45 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > On Thu, Sep 21, 2023 at 2:50 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > ... > > As for close, I don't see why we'd need anything else than the backing ID... > > > > OK. dropped the inode bound mode, updated the example > to do server managed backing id for the rdonly shared fds. > > Pushed this to the fuse-backing-id branches: > > [1] https://github.com/amir73il/linux/commits/fuse-backing-fd > [2] https://github.com/amir73il/libfuse/commits/fuse-backing-fd > > > > > > > The second thing is mmap passthrough. > > > > > > I noticed that the current mmap passthough patch > > > uses the backing file as is, which is fine for io and does > > > pass the tests, but the path of that file is not a "fake path". > > > > > > So either FUSE mmap passthrough needs to allocate > > > a backing file with "fake path" > > > > Drat. > > > > > OR if it is not important, than maybe it is not important for > > > overlayfs either? > > > > We took great pains to make sure that /proc/self/maps, etc display the > > correct overlayfs path. I don't see why FUSE should be different. > > > > Now I will go have a think about how to ease the pain > in this area for vfs. I have some ideas... Ok, posted your original suggestion for opt-in to fake path: https://lore.kernel.org/linux-fsdevel/20231007084433.1417887-1-amir73il@xxxxxxxxx/ Now the problem is that on FUSE_DEV_IOC_BACKING_OPEN ioctl, the fake (fuse) path is not known. We can set the fake path on the first FOPEN_PASSTHROUGH response, but then the whole concept of a backing id that is not bound to a single file/inode becomes a bit fuzzy. One solution is to allocate a backing_file container per fuse file on FOPEN_PASSTHROUGH response. Thanks, Amir.
