Message-ID: <9fdf7a8c04861306b453a78233f4bd6004c465f4.camel@kernel.org>
Date: Mon, 19 Jan 2026 07:30:03 -0500
From: Jeff Layton <jlayton@...nel.org>
To: NeilBrown <neil@...wn.name>, Christoph Hellwig <hch@...radead.org>
Cc: Amir Goldstein <amir73il@...il.com>, Christian Brauner
 <brauner@...nel.org>,  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 Mon, 2026-01-19 at 18:22 +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?
> 

The only one I'm aware of at the moment is cgroupfs. sb->s_export_op
gets populated on that fs, so it's exportable via nfsd.

Its fs does not show up under the v4 pseudoroot, but you can mount
/sys/fs/cgroup with v3 if it's specifically exported. Directories seem
to work properly (I can ls and cd around in there), but the files all
come back empty when read. I didn't play around with trying to write to
any of them.

I didn't do a lot of investigation here, since I didn't actually expect
it to work properly.

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

The whole point of this is to make nfsd export an opt-in in. Exporting
via NFS is something that filesystem developers need to consider
carefully.

cgroupfs is not that big a worry. My bigger concern is new filesystems
being added that do add this for local access and become exportable
without vetting that they will actually work correctly (well, that and
FUSE exportability, which is a bigger can of worms).

There is another approach we could consider: We could move the
export_operations that are needed for local filehandle access into a
new struct filehandle_operations or something. It does mean adding an
extra pointer to the super_block for the new operations vector, but it
might be more intuitive.
-- 
Jeff Layton <jlayton@...nel.org>

Powered by blists - more mailing lists