Re: [RFC PATCH v2 3/6] fuse: initial infrastructure for FUSE_LOOKUP_HANDLE support

[Luis Henriques <luis@igalia.com>]

On Mon, Dec 15 2025, Amir Goldstein wrote:

> On Mon, Dec 15, 2025 at 6:11 PM Bernd Schubert <bschubert@ddn.com> wrote:
>>
>> On 12/15/25 18:06, Amir Goldstein wrote:
>> > On Mon, Dec 15, 2025 at 2:36 PM Bernd Schubert <bschubert@ddn.com> wrote:
>> >>
>> >> Hi Luis,
>> >>
>> >> I'm really sorry for late review.
>> >>
>> >> On 12/12/25 19:12, Luis Henriques wrote:
>> >>> This patch adds the initial infrastructure to implement the LOOKUP_HANDLE
>> >>> operation.  It simply defines the new operation and the extra fuse_init_out
>> >>> field to set the maximum handle size.
>> >>>
>> >>> Signed-off-by: Luis Henriques <luis@igalia.com>
>> >>> ---
>> >>>    fs/fuse/fuse_i.h          | 4 ++++
>> >>>    fs/fuse/inode.c           | 9 ++++++++-
>> >>>    include/uapi/linux/fuse.h | 8 +++++++-
>> >>>    3 files changed, 19 insertions(+), 2 deletions(-)
>> >>>
>> >>> diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
>> >>> index 1792ee6f5da6..fad05fae7e54 100644
>> >>> --- a/fs/fuse/fuse_i.h
>> >>> +++ b/fs/fuse/fuse_i.h
>> >>> @@ -909,6 +909,10 @@ struct fuse_conn {
>> >>>        /* Is synchronous FUSE_INIT allowed? */
>> >>>        unsigned int sync_init:1;
>> >>>
>> >>> +     /** Is LOOKUP_HANDLE implemented by fs? */
>> >>> +     unsigned int lookup_handle:1;
>> >>> +     unsigned int max_handle_sz;
>> >>> +
>
> The bitwise section better be clearly separated from the non bitwise section,
> but as I wrote, the bitwise one is not needed anyway.
>
>> >>>        /* Use io_uring for communication */
>> >>>        unsigned int io_uring;
>> >>>
>> >>> diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
>> >>> index ef63300c634f..bc84e7ed1e3d 100644
>> >>> --- a/fs/fuse/inode.c
>> >>> +++ b/fs/fuse/inode.c
>> >>> @@ -1465,6 +1465,13 @@ static void process_init_reply(struct fuse_mount *fm, struct fuse_args *args,
>> >>>
>> >>>                        if (flags & FUSE_REQUEST_TIMEOUT)
>> >>>                                timeout = arg->request_timeout;
>> >>> +
>> >>> +                     if ((flags & FUSE_HAS_LOOKUP_HANDLE) &&
>> >>> +                         (arg->max_handle_sz > 0) &&
>> >>> +                         (arg->max_handle_sz <= FUSE_MAX_HANDLE_SZ)) {
>> >>> +                             fc->lookup_handle = 1;
>> >>> +                             fc->max_handle_sz = arg->max_handle_sz;
>> >>
>> >> I don't have a strong opinion on it, maybe
>> >>
>> >> if (flags & FUSE_HAS_LOOKUP_HANDLE) {
>> >>          if (!arg->max_handle_sz || arg->max_handle_sz > FUSE_MAX_HANDLE_SZ) {
>> >>                  pr_info_ratelimited("Invalid fuse handle size %d\n, arg->max_handle_sz)
>> >>          } else {
>> >>                  fc->lookup_handle = 1;
>> >>                  fc->max_handle_sz = arg->max_handle_sz;

Right, having some warning here also makes sense.

>> >
>> > Why do we need both?
>> > This seems redundant.
>> > fc->max_handle_sz != 0 is equivalent to fc->lookup_handle
>> > isnt it?
>>
>> I'm personally always worried that some fuse server implementations just
>> don't zero the entire buffer. I.e. areas they don't know about.
>> If all servers are guaranteed to do that the flag would not be needed.
>>
>
> I did not mean that we should not use the flag FUSE_HAS_LOOKUP_HANDLE
> we should definitely use it, but why do we need both
> bool fc->lookup_handle and unsigned fc->max_handle_sz in fuse_conn?
> The first one seems redundant.

OK, I'll drop the ->lookup_handle.  At some point it seemed to make sense
to have both, but it doesn't anymore (maybe I had max_handle_sz stored
somewhere else, not sure).  Thank you for your comments.

Cheers,
-- 
Luís