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

[NeilBrown <neilb@ownmail.net>]

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.

NeilBrown