[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJnrk1ZtS4VfYo03UFO_khcaA6ugHiwtWQqaObB5P_ozFtsCHA@mail.gmail.com>
Date: Wed, 14 Jan 2026 18:29:26 -0800
From: Joanne Koong <joannelkoong@...il.com>
To: Horst Birthelmer <horst@...thelmer.com>
Cc: Miklos Szeredi <miklos@...redi.hu>, Bernd Schubert <bschubert@....com>, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, Horst Birthelmer <hbirthelmer@....com>
Subject: Re: [PATCH v4 3/3] fuse: add an implementation of open+getattr
On Fri, Jan 9, 2026 at 10:27 AM Horst Birthelmer <horst@...thelmer.com> wrote:
>
> From: Horst Birthelmer <hbirthelmer@....com>
>
> The discussion about compound commands in fuse was
> started over an argument to add a new operation that
> will open a file and return its attributes in the same operation.
>
> Here is a demonstration of that use case with compound commands.
>
> Signed-off-by: Horst Birthelmer <hbirthelmer@....com>
> ---
> fs/fuse/file.c | 110 +++++++++++++++++++++++++++++++++++++++++++++++--------
> fs/fuse/fuse_i.h | 7 +++-
> fs/fuse/inode.c | 6 +++
> fs/fuse/ioctl.c | 2 +-
> 4 files changed, 107 insertions(+), 18 deletions(-)
>
> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> index 53744559455d..c0375b32967d 100644
> --- a/fs/fuse/file.c
> +++ b/fs/fuse/file.c
> @@ -152,8 +152,66 @@ static void fuse_file_put(struct fuse_file *ff, bool sync)
> }
> }
>
> +static int fuse_compound_open_getattr(struct fuse_mount *fm, u64 nodeid,
> + int flags, int opcode,
> + struct fuse_file *ff,
> + struct fuse_attr_out *outattrp,
> + struct fuse_open_out *outopenp)
> +{
> + struct fuse_compound_req *compound;
> + struct fuse_args open_args = {};
> + struct fuse_args getattr_args = {};
> + struct fuse_open_in open_in = {};
> + struct fuse_getattr_in getattr_in = {};
> + int err;
> +
> + compound = fuse_compound_alloc(fm, 0);
> + if (IS_ERR(compound))
> + return PTR_ERR(compound);
> +
> + open_in.flags = flags & ~(O_CREAT | O_EXCL | O_NOCTTY);
> + if (!fm->fc->atomic_o_trunc)
> + open_in.flags &= ~O_TRUNC;
> +
> + if (fm->fc->handle_killpriv_v2 &&
> + (open_in.flags & O_TRUNC) && !capable(CAP_FSETID))
> + open_in.open_flags |= FUSE_OPEN_KILL_SUIDGID;
> +
> + fuse_open_args_fill(&open_args, nodeid, opcode, &open_in, outopenp);
> +
> + err = fuse_compound_add(compound, &open_args);
> + if (err)
> + goto out;
> +
> + fuse_getattr_args_fill(&getattr_args, nodeid, &getattr_in, outattrp);
> +
> + err = fuse_compound_add(compound, &getattr_args);
> + if (err)
> + goto out;
> +
> + err = fuse_compound_send(compound);
> + if (err)
> + goto out;
> +
> + err = fuse_compound_get_error(compound, 0);
> + if (err)
> + goto out;
> +
> + err = fuse_compound_get_error(compound, 1);
> + if (err)
> + goto out;
Hmm, if the open succeeds but the getattr fails, why not process it
kernel-side as a success for the open? Especially since on the server
side, libfuse will disassemble the compound request into separate
ones, so the server has no idea the open is even part of a compound.
I haven't looked at the rest of the patch yet but this caught my
attention when i was looking at how fuse_compound_get_error() gets
used.
Thanks,
Joanne
> +
> + ff->fh = outopenp->fh;
> + ff->open_flags = outopenp->open_flags;
> +
> +out:
> + fuse_compound_free(compound);
> + return err;
> +}
> +
Powered by blists - more mailing lists