Message-ID: <3210d04fa2c0b1f4312d10506cac30586cb49a3c.camel@kernel.org>
Date: Wed, 21 Jan 2026 10:18:00 -0500
From: Jeff Layton <jlayton@...nel.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: NeilBrown <neil@...wn.name>, 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 06:47 -0800, Christoph Hellwig wrote:
> On Wed, Jan 21, 2026 at 09:27:38AM -0500, Jeff Layton wrote:
> > Using your definitions, stability is not a problem for Linux
> > filesystems. The filehandles generally don't change after they have
> > been established.
> 
> fat seems to be an exception as far as the 'real' file systems go.
> And it did sound to me like some of the synthetic ones had similar
> issues.
> 

Not sure what we can do about FAT without changing the filehandle
format in some fashion. The export ops just use
generic_encode_ino32_fh, and FAT doesn't have stable inode numbers.
The "nostale" ops seem sane enough but it looks like they only work
with the fs in r/o mode.

...and therein lies a problem. We can't reasonably stop exporting FAT
(even with all of its issues), and it in no way meets the definition of
persistent or unique handles.

> > > 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.
> 
> Unique seems to also only capture part of it, but I could absolutely
> live with it, if the documentation includes all aspecs.  But maybe
> use persistent as in the nfs spec?

The spec also has the concept of uniqueness. There is an attribute for
that:

    5.8.1.10. Attribute 9: unique_handles

    TRUE, if two distinct filehandles are guaranteed to refer to two different file system objects.

So, the NFSv4 spec does allow for non-unique handles (oh, the
humanity). Persistence has more to do with being non-volatile, AFAICT:

FH4_PERSISTENT
        The value of FH4_PERSISTENT is used to indicate a persistent
filehandle, which is valid until the object is removed from the file
system. The server will not return NFS4ERR_FHEXPIRED for this
filehandle. FH4_PERSISTENT is defined as a value in which none of the
bits specified below are set.

In this case, the filesystems we're most concerned about do not provide
uniqueness, but do provide persistence.

> > 
> > 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.
> 
> Do we even want to provide access to them?
> 

The point would be that there would be no need to flag them, since all
filehandles would then meet the technical definition of unique and
persistent (modulo FAT of course).


> > 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.
> 
> I think Amirs patch would take care of that.  Although userland nfs
> servers or other storage applications using the handle syscalls would
> still see them.  Then again fixing the problem that some handles
> did not fulfill the long standing (but not documented well enough)
> semantics probably is a good fix on it's own.

Agreed. We should try to ensure uniqueness and persistence in all
filehandles both for nfsd and userland applications.
-- 
Jeff Layton <jlayton@...nel.org>

Powered by blists - more mailing lists