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

[Jeff Layton]

On Tue, 2026-01-20 at 11:31 +0100, Christian Brauner wrote:
> On Tue, Jan 20, 2026 at 08:41:50PM +1100, NeilBrown wrote:
> > On Tue, 20 Jan 2026, Christian Brauner wrote:
> > > On Tue, Jan 20, 2026 at 07:45:35AM +1100, NeilBrown wrote:
> > > > On Mon, 19 Jan 2026, Christian Brauner wrote:
> > > > > On Mon, Jan 19, 2026 at 06:22:42PM +1100, NeilBrown wrote:
> > > > > > On Mon, 19 Jan 2026, Christoph Hellwig wrote:
> > > > > > > On Mon, Jan 19, 2026 at 10:23:13AM +1100, NeilBrown wrote:
> > > > > > > > > This was Chuck's suggested name. His point was that STABLE means that
> > > > > > > > > the FH's don't change during the lifetime of the file.
> > > > > > > > > 
> > > > > > > > > I don't much care about the flag name, so if everyone likes PERSISTENT
> > > > > > > > > better I'll roll with that.
> > > > > > > > 
> > > > > > > > I don't like PERSISTENT.
> > > > > > > > I'd rather call a spade a spade.
> > > > > > > > 
> > > > > > > >   EXPORT_OP_SUPPORTS_NFS_EXPORT
> > > > > > > > or
> > > > > > > >   EXPORT_OP_NOT_NFS_COMPATIBLE
> > > > > > > > 
> > > > > > > > The issue here is NFS export and indirection doesn't bring any benefits.
> > > > > > > 
> > > > > > > No, it absolutely is not.  And the whole concept of calling something
> > > > > > > after the initial or main use is a recipe for a mess.
> > > > > > 
> > > > > > We are calling it for it's only use.  If there was ever another use, we
> > > > > > could change the name if that made sense.  It is not a public name, it
> > > > > > is easy to change.
> > > > > > 
> > > > > > > 
> > > > > > > Pick a name that conveys what the flag is about, and document those
> > > > > > > semantics well.  This flag is about the fact that for a given file,
> > > > > > > as long as that file exists in the file system the handle is stable.
> > > > > > > Both stable and persistent are suitable for that, nfs is everything
> > > > > > > but.
> > > > > > 
> > > > > > My understanding is that kernfs would not get the flag.
> > > > > > kernfs filehandles do not change as long as the file exist.
> > > > > > But this is not sufficient for the files to be usefully exported.
> > > > > > 
> > > > > > I suspect kernfs does re-use filehandles relatively soon after the
> > > > > > file/object has been destroyed.  Maybe that is the real problem here:
> > > > > > filehandle reuse, not filehandle stability.
> > > > > > 
> > > > > > Jeff: could you please give details (and preserve them in future cover
> > > > > > letters) of which filesystems are known to have problems and what
> > > > > > exactly those problems are?
> > > > > > 
> > > > > > > 
> > > > > > > Remember nfs also support volatile file handles, and other applications
> > > > > > > might rely on this (I know of quite a few user space applications that
> > > > > > > do, but they are kinda hardwired to xfs anyway).
> > > > > > 
> > > > > > The NFS protocol supports volatile file handles.  knfsd does not.
> > > > > > So maybe
> > > > > >   EXPORT_OP_NOT_NFSD_COMPATIBLE
> > > > > > might be better.  or EXPORT_OP_NOT_LINUX_NFSD_COMPATIBLE.
> > > > > > (I prefer opt-out rather than opt-in because nfsd export was the
> > > > > > original purpose of export_operations, but it isn't something
> > > > > > I would fight for)
> > > > > 
> > > > > I prefer one of the variants you proposed here but I don't particularly
> > > > > care. It's not a hill worth dying on. So if Christoph insists on the
> > > > > other name then I say let's just go with it.
> > > > > 
> > > > 
> > > > This sounds like you are recommending that we give in to bullying.
> > > > I would rather the decision be made based on the facts of the case, not
> > > > the opinions that are stated most bluntly.
> > > > 
> > > > I actually think that what Christoph wants is actually quite different
> > > > from what Jeff wants, and maybe two flags are needed.  But I don't yet
> > > > have a clear understanding of what Christoph wants, so I cannot be sure.
> > > 
> > > I've tried to indirectly ask whether you would be willing to compromise
> > > here or whether you want to insist on your alternative name. Apparently
> > > that didn't come through.
> > 
> > This would be the "not a hill worthy dying on" part of your statement.
> > I think I see that implication now.
> > But no, I don't think compromise is relevant.  I think the problem
> > statement as originally given by Jeff is misleading, and people have
> > been misled to an incorrect name.
> > 
> > > 
> > > I'm unclear what your goal is in suggesting that I recommend "we" give
> > > into bullying. All it achieved was to further derail this thread.
> > > 
> > 
> > The "We" is the same as the "us" in "let's just go with it".
> > 
> > 
> > > I also think it's not very helpful at v6 of the discussion to start
> > > figuring out what the actual key rift between Jeff's and Christoph's
> > > position is. If you've figured it out and gotten an agreement and this
> > > is already in, send a follow-up series.
> > 
> > v6?  v2 was posted today.  But maybe you are referring the some other
> > precursors.
> > 
> > The introductory statement in v2 is
> > 
> >    This patchset adds a flag that indicates whether the filesystem supports
> >    stable filehandles (i.e. that they don't change over the life of the
> >    file). It then makes any filesystem that doesn't set that flag
> >    ineligible for nfsd export.
> > 
> > Nobody else questioned the validity of that.  I do.
> > No evidence was given that there are *any* filesystems that don't
> > support stable filehandles.  The only filesystem mentioned is cgroups
> > and it DOES provide stable filehandles.
> 

Across reboot? Not really.

It's quite possible that we may end up with the same "id" numbers in
cgroupfs on a new incarnation of the filesystem after a reboot. The
files in there are not the same ones as the ones before, but their
filehandles may match because kernfs doesn't factor in an i_generation
number.

Could we fix it by adding a random i_generation value or something?
Possibly, but there really isn't a good use-case that I can see for
allowing cgroupfs to be exported via nfsd. Best to disallow it until
someone comes up with one.

> Oh yes we did. And this is a merry-go-round.
> 
> It is very much fine for a filesystems to support file handles without
> wanting to support exporting via NFS. That is especially true for
> in-kernel pseudo filesystems.
> 
> As I've said before multiple times I want a way to allow filesystems
> such as pidfs and nsfs to use file handles without supporting export.
> Whatever that fscking flag is called at this point I fundamentally don't
> care. And we are reliving the same arguments over and over.
> 
> I will _hard NAK_ anything that starts mandating that export of
> filesystems must be allowed simply because their file handles fit export
> criteria. I do not care whether pidfs or nsfs file handles fit the bill.
> They will not be exported.

I don't really care what we call the flag. I do care a little about
what its semantics are, but the effect should be to ensure that fs
maintainers make a conscious decision about whether nfsd export should
be allowed on the filesystem. 

At this point, maybe we should just go with Neil's 
EXPORT_OP_SUPPORTS_NFS_EXPORT or something. It's much more arbitrary,
than trying to base this on criteria about filehandle stability, but it
would give us the effect we want.

-- 
Jeff Layton <jlayton at kernel.org>