Message-ID: <364d2fd98af52a2e2c32ca286decbdc1fe1c80d3.camel@kernel.org>
Date: Wed, 21 Jan 2026 09:27:38 -0500
From: Jeff Layton <jlayton@...nel.org>
To: NeilBrown <neil@...wn.name>, Christoph Hellwig <hch@...radead.org>
Cc: Christian Brauner <brauner@...nel.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 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@...nel.org>

Powered by blists - more mailing lists