linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chuck Lever <cel@kernel.org>
To: NeilBrown <neilb@ownmail.net>, Jeff Layton <jlayton@kernel.org>,
	Olga Kornievskaia <okorniev@redhat.com>,
	Dai Ngo <dai.ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: <linux-nfs@vger.kernel.org>, Chuck Lever <chuck.lever@oracle.com>
Subject: [PATCH v1 0/5] Automatic NFSv4 state revocation on filesystem unmount
Date: Tue, 30 Dec 2025 09:18:33 -0500	[thread overview]
Message-ID: <20251230141838.2547848-1-cel@kernel.org> (raw)

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.

The server also provides no notification to NFS clients when their
state becomes invalid due to filesystem removal. Clients continue
using stale state until they encounter errors, potentially
corrupting data or experiencing mysterious failures long after the
underlying storage disappeared.

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

Chuck Lever (5):
  nfsd: cancel async COPY operations when admin revokes filesystem state
  fs: export pin_insert and pin_remove for modular filesystems
  fs: add pin_insert_group() for superblock-only pins
  nfsd: revoke NFSv4 state when filesystem is unmounted
  nfsd: close cached files on filesystem unmount

 fs/fs_pin.c            |  50 ++++++++
 fs/nfsd/Makefile       |   2 +-
 fs/nfsd/filecache.c    |  39 ++++++
 fs/nfsd/filecache.h    |   1 +
 fs/nfsd/netns.h        |   4 +
 fs/nfsd/nfs4proc.c     | 124 +++++++++++++++++--
 fs/nfsd/nfs4state.c    |  44 +++++--
 fs/nfsd/nfsctl.c       |  11 +-
 fs/nfsd/pin.c          | 272 +++++++++++++++++++++++++++++++++++++++++
 fs/nfsd/state.h        |   9 ++
 fs/nfsd/xdr4.h         |   1 +
 include/linux/fs_pin.h |   1 +
 12 files changed, 537 insertions(+), 21 deletions(-)
 create mode 100644 fs/nfsd/pin.c

-- 
2.52.0


             reply	other threads:[~2025-12-30 14:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-30 14:18 Chuck Lever [this message]
2025-12-30 14:18 ` [PATCH v1 1/5] nfsd: cancel async COPY operations when admin revokes filesystem state Chuck Lever
2025-12-30 23:15   ` NeilBrown
2026-01-06 13:44   ` Jeff Layton
2025-12-30 14:18 ` [PATCH v1 2/5] fs: export pin_insert and pin_remove for modular filesystems Chuck Lever
2025-12-30 23:18   ` NeilBrown
2026-01-06 13:46   ` Jeff Layton
2025-12-30 14:18 ` [PATCH v1 3/5] fs: add pin_insert_group() for superblock-only pins Chuck Lever
2025-12-30 23:34   ` NeilBrown
2026-01-06 15:22   ` Jeff Layton
2026-01-06 15:24     ` Chuck Lever
2025-12-30 14:18 ` [PATCH v1 4/5] nfsd: revoke NFSv4 state when filesystem is unmounted Chuck Lever
2025-12-31  0:10   ` NeilBrown
2025-12-30 14:18 ` [PATCH v1 5/5] nfsd: close cached files on filesystem unmount Chuck Lever
2025-12-31  0:16   ` NeilBrown
2025-12-31  0:28 ` [PATCH v1 0/5] Automatic NFSv4 state revocation " NeilBrown
2025-12-31  2:18   ` Chuck Lever

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251230141838.2547848-1-cel@kernel.org \
    --to=cel@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=dai.ngo@oracle.com \
    --cc=jlayton@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@ownmail.net \
    --cc=okorniev@redhat.com \
    --cc=tom@talpey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).