Re: [f2fs-dev] [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support

[Jeff Layton via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>]

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


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel