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: <8bae31f2-37fc-4a87-98c8-4aa966c812af@ddn.com>
Date: Mon, 15 Dec 2025 17:11:45 +0000
From: Bernd Schubert <bschubert@....com>
To: Amir Goldstein <amir73il@...il.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 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;
>>> +
>>>        /* 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.

Thanks,
Bernd