Re: [PATCH v2 02/21] fuse: prepare for passthrough of inode operations

On Fri, May 15, 2026 at 5:52 PM Joanne Koong <[email protected]> wrote:
>
> From: Amir Goldstein <[email protected]>
>
> So far, fuse passthrough was implemented for read/write/splice/mmap
> operations for regular files opened with FOPEN_PASSTHROUGH.
>
> A backing file is attached to a fuse inode, but only for as long as
> there are FOPEN_PASSTHROUGH files opened on this inode.
>
> We would like to attach a backing file to fuse inode also without an
> open file to allow passthrough of some inode operations.
>
> Add field ops_mask to the input argument of FUSE_DEV_IOC_BACKING_OPEN
> ioctl to declare the operations that would passthrough to the backing
> file once it has been attached to the fuse inode on lookup.
>
> Setting the FUSE_READ/FUSE_WRITE operations in the ops_mask is not
> required because those operations are implied by FOPEN_PASSTHROUGH.
>
> When setting operations other than FUSE_READ/FUSE_WRITE in ops_mask,
> non-regular backing files are allowed, so we need to verify when
> attaching a backing file to a fuse inode, that their file types match.
>
> For simplification of inode attribute caching, for now, require a
> filesystem with FUSE_PASSTHROUGH_INO (one-to-one mapping from fuse inode
> to backing inode) for setting up passthrough of any inode operations.
> We may consider relaxing this requirement for some inode operations
> in the future.
>
> Reviewed-by: Joanne Koong <[email protected]>
> Signed-off-by: Amir Goldstein <[email protected]>
> ---
>  fs/fuse/backing.c         | 13 ++++++++++---
>  fs/fuse/fuse_i.h          | 30 ++++++++++++++++++++++++++++++
>  fs/fuse/iomode.c          | 16 ++++++++++++++++
>  include/uapi/linux/fuse.h |  9 ++++++++-
>  4 files changed, 64 insertions(+), 4 deletions(-)
>
> diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h
> index 4be9ccc5b3ff..0f1e1c1ec367 100644
> --- a/include/uapi/linux/fuse.h
> +++ b/include/uapi/linux/fuse.h
> @@ -243,6 +243,7 @@
>
> +#define FUSE_PASSTHROUGH_OP(op)        (1ULL << ((op) - 1))
> +
> +/* op bits for fuse_backing_map ops_mask */
> +#define FUSE_PASSTHROUGH_OP_READ       FUSE_PASSTHROUGH_OP(FUSE_READ)
> +#define FUSE_PASSTHROUGH_OP_WRITE      FUSE_PASSTHROUGH_OP(FUSE_WRITE)

Do you think we should couple the passthrough op code to the fuse
opcode so closely, instead of defining the passthrough ops separately,
eg doing something like this?:

#define FUSE_PASSTHROUGH_READ         (1 << 0)
#define FUSE_PASSTHROUGH_WRITE       (1 << 1)

In the (far) future when some more advanced passthrough features get
added (eg full subtree passthrough), it seems like we'd want to add a
passthrough op for that, but that wouldn't map to a fuse op. I think
there are also some fuse ops we might skip defining as passthrough ops
but are implicitly passed through (eg FUSE_STATX which is covered by
FUSE_GETATTR), so it seems more intuitive to define the passthrough
ops as describing capabilities rather than implying that it describes
what specific opcodes get passed through?

Thanks,
Joanne