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 for Android: free password hash cracker in your pocket

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

Message-ID: <4ca7053e-68fc-483b-a967-092cd845e9d2@bsbernd.com>
Date: Mon, 15 Dec 2025 19:23:05 +0100
From: Bernd Schubert <bernd@...ernd.com>
To: Amir Goldstein <amir73il@...il.com>, 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 12/15/25 19:09, Amir Goldstein wrote:
> 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.

Ah sorry, you are absolutely right.