Re: [PATCH v2 0/6] Automatic NFSv4 state revocation on filesystem unmount

[Christian Brauner <brauner@kernel.org>]

On Fri, Jan 09, 2026 at 11:25:30AM -0500, Jeff Layton wrote:
> On Wed, 2026-01-07 at 19:40 -0500, Chuck Lever wrote:
> > From: Chuck Lever <chuck.lever@oracle.com>
> > 
> > When an NFS server exports a filesystem and clients hold NFSv4 state
> > (opens, locks, delegations), unmounting the underlying filesystem
> > fails with EBUSY. The /proc/fs/nfsd/unlock_fs interface exists for
> > administrators to manually revoke state before retrying the unmount,
> > but this approach has significant operational drawbacks.
> > 
> > Manual intervention breaks automation workflows. Containerized NFS
> > servers, orchestration systems, and unattended maintenance scripts
> > cannot reliably unmount exported filesystems without implementing
> > custom logic to detect the failure and invoke unlock_fs. System
> > administrators managing many exports face tedious, error-prone
> > procedures when decommissioning storage.
> > 
> > This series enables the NFS server to detect filesystem unmount
> > events and automatically revoke associated state. The mechanism
> > uses the kernel's existing fs_pin infrastructure, which provides
> > callbacks during mount lifecycle transitions.
> > 
> 
> (cc'ing the vfs maintainers)
> 
> One thing I want to point out here is that the only user of fs_pin is
> the BSD process accounting subsystem, which would be really nice to get
> rid of at some point:
> 
> https://lore.kernel.org/linux-fsdevel/20260106-bsd-acct-v1-1-d15564b52c83@kernel.org/
> 
> I suspect the VFS maintainers might want you to use something different
> here so fs_pin can eventually go away too.

git rm -rf ?

> An alternate idea might be to plumb an srcu notifier chain into the
> umount codepath, similar to the lease_notifier_chain in fs/locks.c.
> Then nfsd could register to be notified when there is a umount attempt
> and do the right thing to tear down state.

Doesn't sound too bad.

> 
> 
> > When a filesystem
> > is unmounted, all NFSv4 opens, locks, and delegations referencing
> > it are revoked, async COPY operations are cancelled with
> > NFS4ERR_ADMIN_REVOKED sent to clients, NLM locks are released,
> > and cached file handles are closed.
> > 
> > With automatic revocation, unmount operations complete without
> > administrator intervention once the brief state cleanup finishes.
> > Clients receive immediate notification of state loss through
> > standard NFSv4 error codes, allowing applications to handle the
> > situation appropriately rather than encountering silent failures.
> > 
> > Based on the nfsd-testing branch of:
> > 
> >   https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git/
> > 
> > Changes since v1:
> > - Explain why drop_client() is being renamed
> > - Finish implementing revocation on umount
> > - Rename pin_insert_group
> > - Clarified log output and code comments
> > - Hold nfsd_mutex while closing nfsd_files
> > 
> > Chuck Lever (6):
> >   nfsd: cancel async COPY operations when admin revokes filesystem state
> >   fs: export pin_insert and pin_remove for modular filesystems
> >   fs: add pin_insert_sb() for superblock-only pins
> >   fs: invoke group_pin_kill() during mount teardown
> >   nfsd: revoke NFSv4 state when filesystem is unmounted
> >   nfsd: close cached files on filesystem unmount
> > 
> >  fs/fs_pin.c            |  50 ++++++++
> >  fs/namespace.c         |   2 +
> >  fs/nfsd/Makefile       |   2 +-
> >  fs/nfsd/filecache.c    |  44 +++++++
> >  fs/nfsd/filecache.h    |   1 +
> >  fs/nfsd/netns.h        |   4 +
> >  fs/nfsd/nfs4proc.c     | 124 +++++++++++++++++--
> >  fs/nfsd/nfs4state.c    |  46 +++++--
> >  fs/nfsd/nfsctl.c       |  11 +-
> >  fs/nfsd/pin.c          | 274 +++++++++++++++++++++++++++++++++++++++++
> >  fs/nfsd/state.h        |   9 ++
> >  fs/nfsd/xdr4.h         |   1 +
> >  include/linux/fs_pin.h |   1 +
> >  13 files changed, 548 insertions(+), 21 deletions(-)
> >  create mode 100644 fs/nfsd/pin.c
> 
> -- 
> Jeff Layton <jlayton@kernel.org>