Message-ID: <b491335d12e976e1ea1c07b9c14164ac69d22aea.camel@kernel.org>
Date: Thu, 22 Jan 2026 07:12:36 -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 22:37 -0800, Christoph Hellwig wrote:
> On Wed, Jan 21, 2026 at 10:18:00AM -0500, Jeff Layton wrote:
> > > 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.
> 
> Yeah.  I guess we need to ignore this because of <history>
> 

Yep. This is a case where the handles are not PERSISTENT but I don't
think we can get away with making FAT unexportable. We're probably
stuck with it.

> > > 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.
> 
> Sounds good to me.


Unfortunately, there are already exceptions. Apparently pidfs and
cgroupfs handles (at least) can't be extended because of userspace
expectations:

https://lore.kernel.org/linux-nfs/20260120-irrelevant-zeilen-b3c40a8e6c30@brauner/

My personal take is that we should try to make handle uniqueness a goal
for most existing filesystems, but we're going to have some that can't
achieve that. For them we probably want to be able to flag them so they
can be id'ed by userland.

So, we will need an export_operations flag of some sort
(EXPORT_OP_UNIQUE_HANDLES?). At that point, we'll have to decide
whether to deny nfsd export based on that flag:

We could deny export of any fs that doesn't set the flag, but NFSv4
actually allows the server to advertise that it can't guarantee handle
uniqueness. There isn't much guidance for the client on how to handle
that though and the attribute seems to have the scope of the entire NFS
server.

-- 
Jeff Layton <jlayton@...nel.org>

Powered by blists - more mailing lists