linux-kernel - Re: [RFC PATCH v2 3/6] fuse: initial infrastructure for FUSE_LOOKUP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOQ4uxh-+S_KMSjH6CYRGa--aLfQOeqCTt=22DGSRQUJTJ2bPw@mail.gmail.com>
Date: Mon, 15 Dec 2025 19:09:41 +0100
From: Amir Goldstein <amir73il@...il.com>
To: Bernd Schubert <bschubert@....com>
Cc: Luis Henriques <luis@...lia.com>, Miklos Szeredi <miklos@...redi.hu>, 
	"Darrick J. Wong" <djwong@...nel.org>, Kevin Chen <kchen@....com>, 
	Horst Birthelmer <hbirthelmer@....com>, 
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Matt Harvey <mharvey@...ptrading.com>, 
	"kernel-dev@...lia.com" <kernel-dev@...lia.com>
Subject: Re: [RFC PATCH v2 3/6] fuse: initial infrastructure for
 FUSE_LOOKUP_HANDLE support

On Mon, Dec 15, 2025 at 6:11 PM Bernd Schubert <bschubert@....com> wrote:
>
> On 12/15/25 18:06, Amir Goldstein wrote:
> > On Mon, Dec 15, 2025 at 2:36 PM Bernd Schubert <bschubert@....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@...lia.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;
> >
> > 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.

Thanks,
Amir.