Message-ID: <a35ac736d9ebc6c92a6e7d61aeb5198234102442.camel@kernel.org>
Date: Tue, 20 Jan 2026 07:50:32 -0500
From: Jeff Layton <jlayton@...nel.org>
To: Christian Brauner <brauner@...nel.org>, NeilBrown <neil@...wn.name>
Cc: Christoph Hellwig <hch@...radead.org>, Amir Goldstein
 <amir73il@...il.com>,  Alexander Viro <viro@...iv.linux.org.uk>, Chuck
 Lever <chuck.lever@...cle.com>, Olga Kornievskaia	 <okorniev@...hat.com>,
 Dai Ngo <Dai.Ngo@...cle.com>, Tom Talpey <tom@...pey.com>,  Hugh Dickins
 <hughd@...gle.com>, Baolin Wang <baolin.wang@...ux.alibaba.com>, Andrew
 Morton	 <akpm@...ux-foundation.org>, Theodore Ts'o <tytso@....edu>, Andreas
 Dilger	 <adilger.kernel@...ger.ca>, Jan Kara <jack@...e.com>, Gao Xiang
 <xiang@...nel.org>,  Chao Yu <chao@...nel.org>, Yue Hu
 <zbestahu@...il.com>, Jeffle Xu <jefflexu@...ux.alibaba.com>,  Sandeep
 Dhavale <dhavale@...gle.com>, Hongbo Li <lihongbo22@...wei.com>, Chunhai
 Guo <guochunhai@...o.com>,  Carlos Maiolino	 <cem@...nel.org>, Ilya Dryomov
 <idryomov@...il.com>, Alex Markuze	 <amarkuze@...hat.com>, Viacheslav
 Dubeyko <slava@...eyko.com>, Chris Mason	 <clm@...com>, David Sterba
 <dsterba@...e.com>, Luis de Bethencourt	 <luisbg@...nel.org>, Salah Triki
 <salah.triki@...il.com>, Phillip Lougher	 <phillip@...ashfs.org.uk>, Steve
 French <sfrench@...ba.org>, Paulo Alcantara	 <pc@...guebit.org>, Ronnie
 Sahlberg <ronniesahlberg@...il.com>, Shyam Prasad N	
 <sprasad@...rosoft.com>, Bharath SM <bharathsm@...rosoft.com>, Miklos
 Szeredi	 <miklos@...redi.hu>, Mike Marshall <hubcap@...ibond.com>, Martin
 Brandenburg	 <martin@...ibond.com>, Mark Fasheh <mark@...heh.com>, Joel
 Becker	 <jlbec@...lplan.org>, Joseph Qi <joseph.qi@...ux.alibaba.com>,
 Konstantin Komarov <almaz.alexandrovich@...agon-software.com>, Ryusuke
 Konishi <konishi.ryusuke@...il.com>,  Trond Myklebust <trondmy@...nel.org>,
 Anna Schumaker <anna@...nel.org>, Dave Kleikamp <shaggy@...nel.org>, David
 Woodhouse <dwmw2@...radead.org>, Richard Weinberger <richard@....at>, Jan
 Kara <jack@...e.cz>,  Andreas Gruenbacher	 <agruenba@...hat.com>, OGAWA
 Hirofumi <hirofumi@...l.parknet.co.jp>, Jaegeuk Kim <jaegeuk@...nel.org>,
 linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
 linux-ext4@...r.kernel.org, 	linux-erofs@...ts.ozlabs.org,
 linux-xfs@...r.kernel.org, 	ceph-devel@...r.kernel.org,
 linux-btrfs@...r.kernel.org, 	linux-cifs@...r.kernel.org,
 linux-unionfs@...r.kernel.org, 	devel@...ts.orangefs.org,
 ocfs2-devel@...ts.linux.dev, ntfs3@...ts.linux.dev, 
	linux-nilfs@...r.kernel.org, jfs-discussion@...ts.sourceforge.net, 
	linux-mtd@...ts.infradead.org, gfs2@...ts.linux.dev, 
	linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to
 nfsd export support

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@...nel.org>

Powered by blists - more mailing lists