This is the first part of a much larger patch set that would allow a directory to be marked ‘passthrough’. At a high level, the fuse daemon can return an optional extra argument to FUSE_LOOKUP that contains an fd. Extra fields are added to the fuse_dentry, fuse_inode and fuse_file structs to have a backing path, inode and file respectively. When fuse is performing an operation, it will check for the existence of a backing object and if it exists forward the operation to the backing object. These two patches add the core infrastructure, handling of the extra argument response to lookup, and forwarding open, flush and close to the backing file. This is sufficient to validate the concept. The questions I have: * Is this something that interests the fuse maintainers and community? * Is this approach the correct one? * (if we agree yes to 1 & 2) Detailed analysis of the patches for errors. A few observations: I have matched backing objects to their fuse objects. Currently fuse passthrough puts a backing file into the fuse inode. I’m not quite sure why this was done - it seems to have been a very late change in the passthrough patch sets which happened without comment. It does not really make sense for full directory passthrough since unopened inodes still need to have backing inodes. The one advantage I can see is that it reduces the number of opens/closes of the backing file. However, this may also be a disadvantage - it moves closes, in particular, to an arbitrary point when the inode is flushed from cache. Backing operations need to happen in the context of the daemon, not the caller. (I am a firm believer of this principle.) This is not yet implemented, and is not (currently, and unfortunately) the way Android uses passthough. It is not hard to do, and if these patches are otherwise acceptable, will be added. There was a long discussion about the security issues of using an fd returned from the fuse daemon in the context of fuse passthrough, and the end solution was to use an ioctl to set the backing file. I have used the previously-rejected approach of passing the fd in a struct in the fuse_daemon response. My defense of this approach is * The fd is simply used to pull out the path and inode * All operations are revalidated * Thus there is no risk even if a privileged process with a protected fd is tricked into passing that fd back in this structure. I’m sure we will discuss this at length if this patch set is otherwise deemed valuable, and I am certainly not wedded to this approach. I have written tests to validate this approach using tools/testing/selftests. I don’t want this patch set to get derailed by a discussion of the way I wrote the tests, so I have not included them. I am very open to any and every suggestion as to how (and where) tests should be written for these patches. Paul Lawrence (2): fuse: Add backing file option to lookup fuse: open/close backing file fs/fuse/Kconfig | 13 +++++ fs/fuse/Makefile | 1 + fs/fuse/backing.c | 97 ++++++++++++++++++++++++++++++++ fs/fuse/dev.c | 14 +++++ fs/fuse/dir.c | 108 +++++++++++++++++++++++++----------- fs/fuse/file.c | 34 ++++++++---- fs/fuse/fuse_i.h | 61 +++++++++++++++++++- fs/fuse/inode.c | 114 ++++++++++++++++++++++++++++++++++---- include/uapi/linux/fuse.h | 4 ++ 9 files changed, 392 insertions(+), 54 deletions(-) create mode 100644 fs/fuse/backing.c -- 2.49.0.1112.g889b7c5bd8-goog
