Received-SPF: pass (google.com: domain of linux-nfs+bounces-1515-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
From: NeilBrown <neilb@suse.de>
To: Chuck Lever <chuck.lever@oracle.com>,
	Jeff Layton <jlayton@kernel.org>
Cc: linux-nfs@vger.kernel.org,
	Olga Kornievskaia <kolga@netapp.com>,
	Dai Ngo <Dai.Ngo@oracle.com>,
	Tom Talpey <tom@talpey.com>,
	Christoph Hellwig <hch@lst.de>,
	Tom Haynes <loghyr@gmail.com>
Subject: [PATCH 00/13 v4] nfsd: support admin-revocation of v4 state
Date: Mon, 29 Jan 2024 14:29:22 +1100
Message-ID: <20240129033637.2133-1-neilb@suse.de>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Changes compared with v3:
 - fixed a bug (tested a status flag in sc_type) that kernel test robot reported
 - Changed all NFS4.*STID.* #defines to SC_TYPE_foo or ST_STATUS_foo to match field names
 - fixed problems with accessing ->ls_file correctly in final patch
 - assorted speeling fixes and cosmetic changes
 - added Christoph and Tom to Cc as requested by Chuck


Patchset introduction:

There are cirsumstances where an admin might need to unmount a
filesystem that is NFS-exported and in active use, but does not want to
stop the NFS server completely.  These are certainly unusual
circumstance and doing this might negatively impact any clients acting
on the filesystem, but the admin should be able to do this.

Currently this is quite possible for NFSv3.  Unexporting the filesystem
will ensure no new opens happen, and writing the path name to
/proc/fs/nfsd/unlock_filesystem will ensure anly NLM locks held in the
filesystem are released so that NFSD no longer prevents the filesystem
from being unlocked.

It is not currently possible for NFSv4.  Writing to unlock_filesystem
does not affect NFSv4, which is arguably a bug.  This series fixes the bug.

For NFSv4.1 and later code is straight forward.  We add new state flags
for admin-revoked state (open, lock, deleg, layout) and set the flag
of any state on a filesystem - invalidating any access and closing files
as we go.  While there are any revoked states we report this to the
client in the response to SEQUENCE requests, and it will check and free
any states that need to be freed.

For NFSv4.0 it isn't quite so easy as there is no mechanism for the
client to explicitly acknowledged admin-revoked states.  The approach
this patchset takes is to discard NFSv4.0 admin-revoked states one
lease-time after they were revoked, or immediately for a state that the
client tries to use and gets an "ADMIN_REVOKED" error for.  If the
filestystem has been unmounted (as expected), the client will see STATE
errors before it has a chance to see ADMIN_REVOKED errors, so most often
the timeout will be how states are discarded.

NeilBrown

 [PATCH 01/13] nfsd: remove stale comment in nfs4_show_deleg()
 [PATCH 02/13] nfsd: hold ->cl_lock for hash_delegation_locked()
 [PATCH 03/13] nfsd: don't call functions with side-effecting inside
 [PATCH 04/13] nfsd: avoid race after unhash_delegation_locked()
 [PATCH 05/13] nfsd: split sc_status out of sc_type
 [PATCH 06/13] nfsd: prepare for supporting admin-revocation of state
 [PATCH 07/13] nfsd: allow state with no file to appear in
 [PATCH 08/13] nfsd: report in /proc/fs/nfsd/clients/*/states when
 [PATCH 09/13] nfsd: allow admin-revoked NFSv4.0 state to be freed.
 [PATCH 10/13] nfsd: allow lock state ids to be revoked and then freed
 [PATCH 11/13] nfsd: allow open state ids to be revoked and then freed
 [PATCH 12/13] nfsd: allow delegation state ids to be revoked and then
 [PATCH 13/13] nfsd: allow layout state to be admin-revoked.