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] [day] [month] [year] [list]

Message-ID: <CAOQ4uxhaDboSe0T1tb9ArVDFg9SEQCBmSH3YEGJv_fG0kJmu2Q@mail.gmail.com>
Date: Thu, 6 Nov 2025 17:11:56 +0100
From: Amir Goldstein <amir73il@...il.com>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: Bernd Schubert <bschubert@....com>, 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

On Thu, Nov 6, 2025 at 4:49 PM Darrick J. Wong <djwong@...nel.org> wrote:
>
> On Thu, Nov 06, 2025 at 11:13:01AM +0100, Amir Goldstein wrote:
> > [...]
> >
> > > >>> 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?
>
> Technically speaking, a 12-byte handle could contain anything.  Maybe
> you have a u32 volumeid, inumber, and generation, whereas the flag that
> I was mumbling about would specify the handle format as well.
>
> Speaking of which: should file handles be exporting volume ids for the
> filesystem (btrfs) that supports it?
>

file handles are opaque so the server can put whatever server wants in them
it does not need to put the native fs file handles (in case of passthrough fs
or in case of iomap fs).

Take struct ovl_fh for example, the format of file handles that overlayfs
exports to NFS encapsulates the underlying fs uuid and file handle.

Note that when exporting such a fuse filesystem to NFS, it is still the
responsibility of the exporter to specify an explicit fsid identifier in
/etc/exports for this fuse server type/instance and then the file handles
generated by this server are expected to be unique in the scope of this
NFS export. Not sure how much of this is relevant for the use case
of restarting a fuse server.

Thanks,
Amir.