public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Chuck Lever <cel@kernel.org>
Cc: 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>,
	linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [PATCH v3 0/3] Automatic NFSv4 state revocation on filesystem unmount
Date: Tue, 24 Feb 2026 17:14:24 +0000	[thread overview]
Message-ID: <20260224171424.GC1762976@ZenIV> (raw)
In-Reply-To: <20260224163908.44060-1-cel@kernel.org>

On Tue, Feb 24, 2026 at 11:39:05AM -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
> registers with a new SRCU notifier chain in VFS that fires during
> mount teardown, after processing stuck children but before
> fsnotify_vfsmount_delete(), while SB_ACTIVE is still set. 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.

So anyone can force that just with unshare -U -m date?  Creates
a new namespace, populated by clones of all mounts you see, runs
date(1) in that, then exits, with namespace dissolved.  At that
point all cloned mounts are released, each triggering your notifier
chain...

      parent reply	other threads:[~2026-02-24 17:11 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-24 16:39 [PATCH v3 0/3] Automatic NFSv4 state revocation on filesystem unmount Chuck Lever
2026-02-24 16:39 ` [PATCH v3 1/3] fs: add umount notifier chain for filesystem unmount notification Chuck Lever
2026-02-26  8:48   ` Christian Brauner
2026-02-26 10:52     ` Amir Goldstein
2026-02-26 13:27       ` Chuck Lever
2026-02-26 13:32         ` Jan Kara
2026-02-27 15:10           ` Chuck Lever
2026-03-01 14:37             ` Amir Goldstein
2026-03-01 17:20               ` Chuck Lever
2026-03-01 18:09                 ` Amir Goldstein
2026-03-01 18:19                   ` Chuck Lever
2026-03-02  4:09                     ` NeilBrown
2026-03-02 13:57                       ` Chuck Lever
2026-03-02 15:26                         ` Jan Kara
2026-03-02 17:10                           ` Jeff Layton
2026-03-02 17:37                             ` Jan Kara
2026-03-02 17:53                               ` Jeff Layton
2026-03-04 13:17                                 ` Christian Brauner
2026-03-04 15:15                                   ` Chuck Lever
2026-03-02 20:46                               ` NeilBrown
2026-03-02 17:01                         ` Chuck Lever
2026-03-02 20:36                           ` NeilBrown
2026-03-03 20:02                             ` Chuck Lever
2026-03-03 21:23                               ` NeilBrown
2026-03-03 22:50                                 ` Chuck Lever
2026-03-04  1:01                                   ` NeilBrown
2026-03-04 13:05                             ` Christian Brauner
2026-02-24 16:39 ` [PATCH v3 2/3] nfsd: revoke NFSv4 state when filesystem is unmounted Chuck Lever
2026-02-24 16:39 ` [PATCH v3 3/3] nfsd: close cached files on filesystem unmount Chuck Lever
2026-02-24 17:14 ` Al Viro [this message]

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=20260224171424.GC1762976@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=cel@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=dai.ngo@oracle.com \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.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