[PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support

[Christoph Hellwig]

On Wed, Jan 14, 2026 at 10:34:04AM +0100, Amir Goldstein wrote:
> On Wed, Jan 14, 2026 at 7:28 AM Christoph Hellwig <hch at infradead.org> wrote:
> >
> > On Tue, Jan 13, 2026 at 12:06:42PM -0500, Jeff Layton wrote:
> > > Fair point, but it's not that hard to conceive of a situation where
> > > someone inadvertantly exports cgroupfs or some similar filesystem:
> >
> > Sure.  But how is this worse than accidentally exporting private data
> > or any other misconfiguration?
> >
> 
> My POV is that it is less about security (as your question implies), and
> more about correctness.

I was just replying to Jeff.

> The special thing about NFS export, as opposed to, say, ksmbd, is
> open by file handle, IOW, the export_operations.
> 
> I perceive this as a very strange and undesired situation when NFS
> file handles do not behave as persistent file handles.

That is not just very strange, but actually broken (discounting the
obscure volatile file handles features not implemented in Linux NFS
and NFSD).  And the export ops always worked under the assumption
that these file handles are indeed persistent.  If they're not we
do have a problem.

> 
> cgroupfs, pidfs, nsfs, all gained open_by_handle_at() capability for
> a known reason, which was NOT NFS export.
> 
> If the author of open_by_handle_at() support (i.e. brauner) does not
> wish to imply that those fs should be exported to NFS, why object?

Because "want to export" is a stupid category.

OTOH "NFS exporting doesn't actually properly work because someone
overloaded export_ops with different semantics" is a valid category.

> We could have the opt-in/out of NFS export fixes per EXPORT_OP_
> flags and we could even think of allowing admin to make this decision
> per vfsmount (e.g. for cgroupfs).
> 
> In any case, I fail to see how objecting to the possibility of NFS export
> opt-out serves anyone.

You're still think of it the wrong way.  If we do have file systems
that break the original exportfs semantics we need to fix that, and
something like a "stable handles" flag will work well for that.  But
a totally arbitrary "is exportable" flag is total nonsense.