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

[Jeff Layton <jlayton@kernel.org>]

On Wed, 2026-01-21 at 21:34 +1100, NeilBrown wrote:
> On Wed, 21 Jan 2026, Christoph Hellwig wrote:
> 
> > 
> > > 
> > > It took me a while to sift through the code/patches/comments and come to
> > > this understanding and I apologise if I wasn't as clear earlier.  But
> > > my intuition was always that file handle stability was never the real
> > > issue, and maintainer choice was.  Hence my rejection of the
> > > "STABLE_HANDLES" name.
> > 
> > Why do you keep ignoring the fat that the stable handles are really
> > important for anyone wanting to actually use them for their original
> > storage purpose, be that for knfsd, a userland nfs damon, or other
> > storage applications in userspace despite explaining this countless
> > times?
> > 
> 
> It isn't that I don't think they are important.  It is that I think they
> are universally provided (when not connectable).
> If we add an EXPORT_OP_STABLE_FILEHANDLES flag, I believe we would need to
> set it on every export_operations structure.  So what would be the
> point?
> 

I see your point.

Using your definitions, stability is not a problem for Linux
filesystems. The filehandles generally don't change after they have
been established.

Uniqueness however _is_ a problem as we can end up with valid handles
for files that have been recreated across a reboot with some
filesystems (esp. "synthetic" ones like cgroupfs, pidfs, etc.). Naming
the flag STABLE conflates the two.

In an earlier email, HCH said:

> 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.

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.

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.

-- 
Jeff Layton <jlayton@kernel.org>