linux-kernel - Re: [RFC] Another take at restarting FUSE servers

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: <CAOQ4uxgKZ3Hc+fMg_azN=DWLTj4fq0hsoU4n0M8GA+DsMgJW4g@mail.gmail.com>
Date: Thu, 6 Nov 2025 11:13:01 +0100
From: Amir Goldstein <amir73il@...il.com>
To: Bernd Schubert <bschubert@....com>, "Darrick J. Wong" <djwong@...nel.org>
Cc: Luis Henriques <luis@...lia.com>, Bernd Schubert <bernd@...ernd.com>, "Theodore Ts'o" <tytso@....edu>, 
	Miklos Szeredi <miklos@...redi.hu>, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Kevin Chen <kchen@....com>
Subject: Re: [RFC] Another take at restarting FUSE servers

[...]

> >>> fuse_entry_out was extended once and fuse_reply_entry()
> >>> sends the size of the struct.
> >>
> >> Sorry, I'm confused. Where does fuse_reply_entry() send the size?

Sorry, I meant to say that the reply size is variable.
The size is obviously determined at init time.

> >>
> >>> However fuse_reply_create() sends it with fuse_open_out
> >>> appended and fuse_add_direntry_plus() does not seem to write
> >>> record size at all, so server and client will need to agree on the
> >>> size of fuse_entry_out and this would need to be backward compat.
> >>> If both server and client declare support for FUSE_LOOKUP_HANDLE
> >>> it should be fine (?).
> >>
> >> If max_handle size becomes a value in fuse_init_out, server and
> >> client would use it? I think appended fuse_open_out could just
> >> follow the dynamic actual size of the handle - code that
> >> serializes/deserializes the response has to look up the actual
> >> handle size then. For example I wouldn't know what to put in
> >> for any of the example/passthrough* file systems as handle size -
> >> would need to be 128B, but the actual size will be typically
> >> much smaller.
> >
> > name_to_handle_at ?
> >
> > I guess the problem here is that technically speaking filesystems could
> > have variable sized handles depending on the file.  Sometimes you encode
> > just the ino/gen of the child file, but other times you might know the
> > parent and put that in the handle too.
>
> Yeah, I don't think it would be reliable for *all* file systems to use
> name_to_handle_at on startup on some example file/directory. At least
> not without knowing all the details of the underlying passthrough file
> system.
>

Maybe it's not a world-wide general solution, but it is a practical one.

My fuse_passthrough library knows how to detect xfs and ext4 and
knows about the size of their file handles.
https://github.com/amir73il/libfuse/blob/fuse_passthrough/passthrough/fuse_passthrough.cpp#L645

A server could optimize for max_handle_size if it knows it or use
MAX_HANDLE_SZ if it doesn't.

Keep in mind that for the sake of restarting fuse servers (title of this thread)
file handles do not need to be the actual filesystem file handles.
Server can use its own pid as generation and then all inodes get
auto invalidated on server restart.

Not invalidating file handles on server restart, because the file handles
are persistent file handles is an optimization.

LOOKUP_HANDLE still needs to provide the inode+gen of the parent
which LOOKUP currently does not.

I did not understand why Darrick's suggestion of a flag that ino+gen
suffice is any different then max_handle_size = 12 and using the
standard FILEID_INO64_GEN in that case?

Thanks,
Amir.