From: Luis Henriques <luis@igalia.com>
To: Bernd Schubert <bschubert@ddn.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
Amir Goldstein <amir73il@gmail.com>,
"Darrick J. Wong" <djwong@kernel.org>,
Kevin Chen <kchen@ddn.com>,
Horst Birthelmer <hbirthelmer@ddn.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Matt Harvey <mharvey@jumptrading.com>,
"kernel-dev@igalia.com" <kernel-dev@igalia.com>
Subject: Re: [RFC PATCH v2 4/6] fuse: implementation of the FUSE_LOOKUP_HANDLE operation
Date: Wed, 17 Dec 2025 16:53:21 +0000 [thread overview]
Message-ID: <87o6nxoxry.fsf@wotan.olymp> (raw)
In-Reply-To: <5d08a442-fd74-432f-a5da-4fa9db65e815@ddn.com> (Bernd Schubert's message of "Wed, 17 Dec 2025 16:02:58 +0100")
On Wed, Dec 17 2025, Bernd Schubert wrote:
> On 12/16/25 12:48, Luis Henriques wrote:
>> On Mon, Dec 15 2025, Bernd Schubert wrote:
>>
>>> On 12/12/25 19:12, Luis Henriques wrote:
>>>> The implementation of LOOKUP_HANDLE modifies the LOOKUP operation to include
>>>> an extra inarg: the file handle for the parent directory (if it is
>>>> available). Also, because fuse_entry_out now has a extra variable size
>>>> struct (the actual handle), it also sets the out_argvar flag to true.
>>>>
>>>> Most of the other modifications in this patch are a fallout from these
>>>> changes: because fuse_entry_out has been modified to include a variable size
>>>> struct, every operation that receives such a parameter have to take this
>>>> into account:
>>>>
>>>> CREATE, LINK, LOOKUP, MKDIR, MKNOD, READDIRPLUS, SYMLINK, TMPFILE
>>>>
>>>> Signed-off-by: Luis Henriques <luis@igalia.com>
>>>> ---
>>>> fs/fuse/dev.c | 16 +++++++
>>>> fs/fuse/dir.c | 87 ++++++++++++++++++++++++++++++---------
>>>> fs/fuse/fuse_i.h | 34 +++++++++++++--
>>>> fs/fuse/inode.c | 69 +++++++++++++++++++++++++++----
>>>> fs/fuse/readdir.c | 10 ++---
>>>> include/uapi/linux/fuse.h | 8 ++++
>>>> 6 files changed, 189 insertions(+), 35 deletions(-)
>>>>
>>>> diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
>>>> index 629e8a043079..fc6acf45ae27 100644
>>>> --- a/fs/fuse/dev.c
>>>> +++ b/fs/fuse/dev.c
>>>> @@ -606,6 +606,22 @@ static void fuse_adjust_compat(struct fuse_conn *fc, struct fuse_args *args)
>>>> if (fc->minor < 4 && args->opcode == FUSE_STATFS)
>>>> args->out_args[0].size = FUSE_COMPAT_STATFS_SIZE;
>>>>
>>>> + if (fc->minor < 45) {
>>>
>>> Could we use fc->lookup_handle here? Numbers are hard with backports
>>
>> To be honest, I'm not sure this code is correct. I just followed the
>> pattern. I'll need to dedicate some more time looking into this,
>> specially because the READDIRPLUS op handling is still TBD.
>>
>> <snip>
>>
>>>> @@ -505,6 +535,30 @@ struct inode *fuse_iget(struct super_block *sb, u64 nodeid,
>>>> if (!inode)
>>>> return NULL;
>>>>
>>>> + fi = get_fuse_inode(inode);
>>>> + if (fc->lookup_handle) {
>>>> + if ((fh == NULL) && (nodeid != FUSE_ROOT_ID)) {
>>>> + pr_err("NULL file handle for nodeid %llu\n", nodeid);
>>>> + iput(inode);
>>>> + return NULL;
>>>
>>> Hmm, so there are conditions like "if (fi && fi->fh) {" in lookup and I
>>> was thinking "nice, fuse-server can decide to skip the fh for some
>>> inodes like FUSE_ROOT_ID. But now it gets forbidden here. In combination
>>> with the other comment in fuse_inode_handle_alloc(), could be allocate
>>> here to the needed size and allow fuse-server to not send the handle
>>> for some files?
>>
>> I'm not sure the code is consistent with this regard, but here I'm doing
>> exactly that: allowing the fh to be NULL only for FUSE_ROOT_ID. Or did I
>> misunderstood your comment?
>
> Sorry for late reply.
>
> Yeah sorry, what I meant is that the file handle size might be different
> for any of the inodes, in between 0 and max-size for any of the inodes?
So, as per the other discussion of this patch, Miklos was suggesting the
maximum size negotiation could be totally removed, and the allocation
would be done on-demand [1]. (But probably still keeping an hard limit on
MAX_HANDLE_SZ.)
In that case, different inodes could indeed have different file handle
sizes, defined by the server. Which would be nice, I guess.
But as I also mentioned in other places, there are already a bunch of
changes, and I need going back to the drawing board :-)
[1] https://lore.kernel.org/all/CAJfpegszP+2XA=vADK4r09KU30BQd-r9sNu2Dog88yLG8iV7WQ@mail.gmail.com
Cheers,
--
Luís
next prev parent reply other threads:[~2025-12-17 16:53 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-12 18:12 [RFC PATCH v2 0/6] fuse: LOOKUP_HANDLE operation Luis Henriques
2025-12-12 18:12 ` [RFC PATCH v2 1/6] fuse: store index of the variable length argument Luis Henriques
2025-12-12 18:12 ` [RFC PATCH v2 2/6] fuse: move fuse_entry_out structs out of the stack Luis Henriques
2025-12-15 14:03 ` Bernd Schubert
2025-12-16 10:30 ` Luis Henriques
2025-12-12 18:12 ` [RFC PATCH v2 3/6] fuse: initial infrastructure for FUSE_LOOKUP_HANDLE support Luis Henriques
2025-12-15 13:36 ` Bernd Schubert
2025-12-15 17:06 ` Amir Goldstein
2025-12-15 17:11 ` Bernd Schubert
2025-12-15 18:09 ` Amir Goldstein
2025-12-15 18:23 ` Bernd Schubert
2025-12-16 10:36 ` Luis Henriques
2025-12-16 10:19 ` Miklos Szeredi
2025-12-16 11:33 ` Luis Henriques
2025-12-16 11:46 ` Miklos Szeredi
2025-12-16 12:02 ` Luis Henriques
2025-12-12 18:12 ` [RFC PATCH v2 4/6] fuse: implementation of the FUSE_LOOKUP_HANDLE operation Luis Henriques
2025-12-15 17:39 ` Bernd Schubert
2025-12-16 11:48 ` Luis Henriques
2025-12-17 10:18 ` Amir Goldstein
2025-12-17 14:45 ` Luis Henriques
2025-12-17 15:02 ` Bernd Schubert
2025-12-17 16:53 ` Luis Henriques [this message]
2025-12-16 8:49 ` Joanne Koong
2025-12-16 8:54 ` Bernd Schubert
2025-12-17 0:32 ` Joanne Koong
2025-12-17 1:00 ` Darrick J. Wong
2025-12-17 2:48 ` Joanne Koong
2025-12-17 9:38 ` Luis Henriques
2025-12-17 10:08 ` Miklos Szeredi
2025-12-17 16:17 ` Luis Henriques
2025-12-16 10:39 ` Miklos Szeredi
2025-12-16 10:51 ` Amir Goldstein
2025-12-16 11:07 ` Miklos Szeredi
2026-01-09 11:57 ` Luis Henriques
2026-01-09 12:38 ` Miklos Szeredi
2026-01-09 14:45 ` Luis Henriques
2026-01-09 14:56 ` Horst Birthelmer
2026-01-09 17:07 ` Luis Henriques
2026-01-12 7:43 ` Horst Birthelmer
2026-01-09 15:20 ` Miklos Szeredi
2026-01-09 15:03 ` Amir Goldstein
2026-01-09 15:37 ` Miklos Szeredi
2026-01-09 15:56 ` Bernd Schubert
2026-01-09 16:28 ` Miklos Szeredi
2026-01-09 17:16 ` Luis Henriques
2026-01-09 18:29 ` Amir Goldstein
2026-01-09 19:01 ` Miklos Szeredi
2026-01-09 19:28 ` Amir Goldstein
2026-01-09 19:12 ` Bernd Schubert
2026-01-09 19:55 ` Horst Birthelmer
2026-01-21 17:56 ` Luis Henriques
2026-01-21 18:16 ` Horst Birthelmer
2026-01-21 18:28 ` Bernd Schubert
2026-01-21 18:36 ` Horst Birthelmer
2026-01-21 18:49 ` Bernd Schubert
2026-01-21 19:00 ` Horst Birthelmer
2026-01-21 19:03 ` Bernd Schubert
2026-01-21 19:12 ` Horst Birthelmer
2026-01-22 9:52 ` Luis Henriques
2026-01-22 10:20 ` Horst Birthelmer
2026-01-22 10:35 ` Bernd Schubert
2026-01-22 10:53 ` Luis Henriques
2026-01-22 10:59 ` Horst Birthelmer
2026-01-22 11:25 ` Luis Henriques
2026-01-22 11:32 ` Bernd Schubert
2026-01-22 12:34 ` Horst Birthelmer
2025-12-12 18:12 ` [RFC PATCH v2 5/6] fuse: factor out NFS export related code Luis Henriques
2025-12-14 15:13 ` Amir Goldstein
2025-12-15 12:05 ` Luis Henriques
2025-12-12 18:12 ` [RFC PATCH v2 6/6] fuse: implementation of export_operations with FUSE_LOOKUP_HANDLE Luis Henriques
2025-12-16 10:58 ` Miklos Szeredi
2025-12-16 17:06 ` Luis Henriques
2025-12-16 20:12 ` Horst Birthelmer
2025-12-17 17:02 ` Luis Henriques
2025-12-17 18:02 ` Horst Birthelmer
2025-12-16 11:01 ` Amir Goldstein
2025-12-16 17:26 ` Luis Henriques
2025-12-14 17:02 ` [RFC PATCH v2 0/6] fuse: LOOKUP_HANDLE operation Askar Safin
2025-12-15 12:08 ` Luis Henriques
2025-12-16 0:33 ` Askar Safin
2025-12-16 17:36 ` Luis Henriques
2025-12-16 18:49 ` Bernd Schubert
2025-12-16 22:45 ` Askar Safin
2025-12-25 7:42 ` Askar Safin
2026-01-04 22:38 ` Askar Safin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o6nxoxry.fsf@wotan.olymp \
--to=luis@igalia.com \
--cc=amir73il@gmail.com \
--cc=bschubert@ddn.com \
--cc=djwong@kernel.org \
--cc=hbirthelmer@ddn.com \
--cc=kchen@ddn.com \
--cc=kernel-dev@igalia.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mharvey@jumptrading.com \
--cc=miklos@szeredi.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox