Re: [PATCH v5 0/7] Automatic NFSv4 state revocation on filesystem unmount

[Jeff Layton <jlayton@kernel.org>]

On Thu, 2026-03-26 at 13:55 -0400, Chuck Lever wrote:
> 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_ip and
> /proc/fs/nfsd/unlock_fs procfs interfaces handle this, but have
> no netlink equivalents, and unlock_fs operates at whole-superblock
> granularity.
> 
> This series adds three new NFSD netlink commands, each with its own
> attribute set:
> 
>  - NFSD_CMD_UNLOCK_IP releases NLM locks held by a client IP
>    address. Netlink equivalent of write_unlock_ip.
> 
>  - NFSD_CMD_UNLOCK_FILESYSTEM revokes all NFS state on a
>    superblock. Netlink equivalent of write_unlock_fs.
> 
>  - NFSD_CMD_UNLOCK_EXPORT revokes NFSv4 state acquired through
>    exports of a specific path, regardless of client.
> 
> UNLOCK_FILESYSTEM and UNLOCK_EXPORT serve different intents.
> UNLOCK_FILESYSTEM means "unmounting /data, release everything
> on this superblock." UNLOCK_EXPORT means "no clients remain for
> /data/projectA, release only the state acquired through exports
> of that path." Userspace (exportfs -u) sends UNLOCK_EXPORT after
> removing the last client for a given path, enabling the underlying
> filesystem to be unmounted.
> 
> The path-only design for UNLOCK_EXPORT avoids the auth_domain
> naming complexity (use_ipaddr vs hostname-based domains) by not
> requiring the caller to identify a specific client. Since this
> mechanism is to be used to enable umount, this seemed like a
> reasonable compromise.
> 
> ---
> Changes since v4:
> - 1/9 has been queued in nfsd-testing
> - Split single NFSD_CMD_UNLOCK into three separate commands
> - UNLOCK_EXPORT takes path only, no client attribute to avoid
>   auth_domain naming complexity with use_ipaddr
> 
> Changes since v3:
> - All VFS changes replaced with new netlink "unlock" operation
> 
> Changes since v2:
> - Replace fs_pin with an SRCU umount notifier chain in VFS
> - Merge the pending COPY cancellation patch
> - Replace xa_cmpxchg() with xa_insert()
> - Use cancel_work_sync() instead of flush_workqueue()
> - Remove rcu_barrier()
> - Correct misleading claims in kdoc comments and commit messages
> 
> 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 (7):
>       NFSD: Extract revoke_one_stid() utility function
>       NFSD: Add NFSD_CMD_UNLOCK_IP netlink command
>       NFSD: Add NFSD_CMD_UNLOCK_FILESYSTEM netlink command
>       NFSD: Replace idr_for_each_entry_ul in find_one_sb_stid()
>       NFSD: Track svc_export in nfs4_stid
>       NFSD: Add NFSD_CMD_UNLOCK_EXPORT netlink command
>       NFSD: Close cached file handles when revoking export state
> 
>  Documentation/netlink/specs/nfsd.yaml |  61 +++++++++
>  fs/nfsd/filecache.c                   |  46 +++++++
>  fs/nfsd/filecache.h                   |   1 +
>  fs/nfsd/netlink.c                     |  36 ++++++
>  fs/nfsd/netlink.h                     |   3 +
>  fs/nfsd/nfs4layouts.c                 |   2 +
>  fs/nfsd/nfs4state.c                   | 226 +++++++++++++++++++++++-----------
>  fs/nfsd/nfsctl.c                      | 126 ++++++++++++++++++-
>  fs/nfsd/state.h                       |   6 +
>  fs/nfsd/trace.h                       |  32 ++++-
>  include/uapi/linux/nfsd_netlink.h     |  24 ++++
>  11 files changed, 484 insertions(+), 79 deletions(-)
> ---
> base-commit: 65058e9e9b20619f920397f529072e853dd43811
> change-id: 20260318-umount-kills-nfsv4-state-138218f2f4e0
> 
> Best regards,
> --  
> Chuck Lever

This all looks good to me. A couple of minor nits, but nothing that
looks wrong. I know you intend to use exportfs to drive the
UNLOCK_EXPORT. What are your plans for the userland bits to drive the
other two commands?

Reviewed-by: Jeff Layton <jlayton@kernel.org>