Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

On Wed, 2026-01-21 at 06:47 -0800, Christoph Hellwig wrote:
> On Wed, Jan 21, 2026 at 09:27:38AM -0500, Jeff Layton wrote:
> > Using your definitions, stability is not a problem for Linux
> > filesystems. The filehandles generally don't change after they have
> > been established.
> 
> fat seems to be an exception as far as the 'real' file systems go.
> And it did sound to me like some of the synthetic ones had similar
> issues.
> 

Not sure what we can do about FAT without changing the filehandle
format in some fashion. The export ops just use
generic_encode_ino32_fh, and FAT doesn't have stable inode numbers.
The "nostale" ops seem sane enough but it looks like they only work
with the fs in r/o mode.

...and therein lies a problem. We can't reasonably stop exporting FAT
(even with all of its issues), and it in no way meets the definition of
persistent or unique handles.

> > > We'll still need a stable handles flag, and expose it to userspace
> > > to avoid applications being tricked into using broken non-stable
> > > file handles.  We should have caught that when they were added, but
> > > didn't unfortunately.
> > > 
> > 
> > If we assume he meant "unique handles" flag, then I think we're all
> > mostly in agreement here.  As far as this patchset goes: what if we
> > were to just rename EXPORT_OP_STABLE_HANDLES to
> > EXPORT_OP_UNIQUE_HANDLES (and clean up the documentation), since that's
> > the main issue for existing filesystems. It would be fairly simple to
> > advertise handle uniqueness using statx or something.
> 
> Unique seems to also only capture part of it, but I could absolutely
> live with it, if the documentation includes all aspecs.  But maybe
> use persistent as in the nfs spec?

The spec also has the concept of uniqueness. There is an attribute for
that:

    5.8.1.10. Attribute 9: unique_handles

    TRUE, if two distinct filehandles are guaranteed to refer to two different file system objects.

So, the NFSv4 spec does allow for non-unique handles (oh, the
humanity). Persistence has more to do with being non-volatile, AFAICT:

FH4_PERSISTENT
        The value of FH4_PERSISTENT is used to indicate a persistent
filehandle, which is valid until the object is removed from the file
system. The server will not return NFS4ERR_FHEXPIRED for this
filehandle. FH4_PERSISTENT is defined as a value in which none of the
bits specified below are set.

In this case, the filesystems we're most concerned about do not provide
uniqueness, but do provide persistence.

> > 
> > Alternately, instead of denying access to these filesystems, we could
> > just fix these filesystems to create unique handles (a'la random
> > i_generation value or something similar). That should mostly prevent
> > filehandles from being reusable across a reboot on these filesystems.
> 
> Do we even want to provide access to them?
> 

The point would be that there would be no need to flag them, since all
filehandles would then meet the technical definition of unique and
persistent (modulo FAT of course).


> > That would leave cgroupfs and the like exportable via nfsd, but as you
> > point out, we can't deny export by userland servers. If people want to
> > do this kind of crazy stuff, maybe we shouldn't deny them after all.
> 
> I think Amirs patch would take care of that.  Although userland nfs
> servers or other storage applications using the handle syscalls would
> still see them.  Then again fixing the problem that some handles
> did not fulfill the long standing (but not documented well enough)
> semantics probably is a good fix on it's own.

Agreed. We should try to ensure uniqueness and persistence in all
filehandles both for nfsd and userland applications.
-- 
Jeff Layton <[email protected]>