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

[Jeff Layton]

On Wed, 2026-01-14 at 05:06 -0800, Christoph Hellwig wrote:
> 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.
> 

cgroupfs definitely doesn't behave as expected when exported via NFS.
The files aren't readable, at least. I'd also be surprised if the
filehandles were stable across a reboot, which is sort of necessary for
proper operation. I didn't test writing, but who knows whether that
might also just not work, crash the box, or do something else entirely.

I imagine this is the case for all sorts of filesystems like /proc,
/sys, etc. Those aren't exportable today (to my knowledge), but we're
growing export_operations across a wide range of fs's these days.

I'd prefer that we require someone to take the deliberate step to say
"yes, allow nfsd to access this type of filesystem".

> > 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.

The problem there is that we very much do want to keep tmpfs
exportable, but it doesn't have stable handles (per-se).
-- 
Jeff Layton <jlayton at kernel.org>