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>
Subject: [PATCH 09/11] nfsd: allow open state ids to be revoked and then freed
Date: Fri, 24 Nov 2023 11:23:21 +1100 [thread overview]
Message-ID: <20231124002504.19515-10-neilb@suse.de> (raw)
In-Reply-To: <20231124002504.19515-1-neilb@suse.de>
Revoking state through 'unlock_filesystem' now revokes any open states
found. When the stateids are then freed by the client, the revoked
stateids will be cleaned up correctly.
Possibly the related lock states should be revoked too, but a
subsequent patch will do that for all lock state on the superblock.
Signed-off-by: NeilBrown <neilb@suse.de>
---
fs/nfsd/nfs4state.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 0f52e10fbdfb..8712eb81123f 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -1708,7 +1708,7 @@ void nfsd4_revoke_states(struct net *net, struct super_block *sb)
unsigned int idhashval;
unsigned int sc_types;
- sc_types = NFS4_LOCK_STID;
+ sc_types = NFS4_OPEN_STID | NFS4_LOCK_STID;
spin_lock(&nn->client_lock);
for (idhashval = 0; idhashval < CLIENT_HASH_MASK; idhashval++) {
@@ -1723,6 +1723,22 @@ void nfsd4_revoke_states(struct net *net, struct super_block *sb)
spin_unlock(&nn->client_lock);
switch (stid->sc_type) {
+ case NFS4_OPEN_STID:
+ stp = openlockstateid(stid);
+ mutex_lock_nested(&stp->st_mutex,
+ OPEN_STATEID_MUTEX);
+
+ spin_lock(&clp->cl_lock);
+ if (stid->sc_status == 0) {
+ stid->sc_status |=
+ NFS4_STID_ADMIN_REVOKED;
+ atomic_inc(&clp->cl_admin_revoked);
+ spin_unlock(&clp->cl_lock);
+ release_all_access(stp);
+ } else
+ spin_unlock(&clp->cl_lock);
+ mutex_unlock(&stp->st_mutex);
+ break;
case NFS4_LOCK_STID:
stp = openlockstateid(stid);
mutex_lock_nested(&stp->st_mutex,
@@ -4692,6 +4708,13 @@ static void nfsd_drop_revoked_stid(struct nfs4_stid *s)
bool unhashed;
switch (s->sc_type) {
+ case NFS4_OPEN_STID:
+ stp = openlockstateid(s);
+ if (unhash_open_stateid(stp, &reaplist))
+ put_ol_stateid_locked(stp, &reaplist);
+ spin_unlock(&cl->cl_lock);
+ free_ol_stateid_reaplist(&reaplist);
+ break;
case NFS4_LOCK_STID:
stp = openlockstateid(s);
unhashed = unhash_lock_stateid(stp);
--
2.42.1
next prev parent reply other threads:[~2023-11-24 4:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-24 0:23 [PATCH 00/11 v4] nfsd: support admin-revocation of v4 state NeilBrown
2023-11-24 0:23 ` [PATCH 01/11] nfsd: hold ->cl_lock for hash_delegation_locked() NeilBrown
2023-11-24 0:23 ` [PATCH 02/11] nfsd: don't call functions with side-effecting inside WARN_ON() NeilBrown
2023-11-27 13:00 ` Jeff Layton
2023-11-24 0:23 ` [PATCH 03/11] nfsd: avoid race after unhash_delegation_locked() NeilBrown
2023-11-24 0:23 ` [PATCH 04/11] nfsd: split sc_status out of sc_type NeilBrown
2023-11-27 13:17 ` Jeff Layton
2023-11-24 0:23 ` [PATCH 05/11] nfsd: prepare for supporting admin-revocation of state NeilBrown
2023-11-24 0:23 ` [PATCH 06/11] nfsd: allow admin-revoked state to appear in /proc/fs/nfsd/clients/*/states NeilBrown
2023-11-24 0:23 ` [PATCH 07/11] nfsd: allow admin-revoked NFSv4.0 state to be freed NeilBrown
2023-11-24 0:23 ` [PATCH 08/11] nfsd: allow lock state ids to be revoked and then freed NeilBrown
2023-11-24 0:23 ` NeilBrown [this message]
2023-11-24 0:23 ` [PATCH 10/11] nfsd: allow delegation " NeilBrown
2023-11-24 0:23 ` [PATCH 11/11] nfsd: allow layout state to be admin-revoked NeilBrown
-- strict thread matches above, loose matches on Subject: below --
2023-11-24 0:28 [PATCH 00/11 v4] nfsd: support admin-revocation of v4 state NeilBrown
2023-11-24 0:28 ` [PATCH 09/11] nfsd: allow open state ids to be revoked and then freed NeilBrown
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=20231124002504.19515-10-neilb@suse.de \
--to=neilb@suse.de \
--cc=Dai.Ngo@oracle.com \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=kolga@netapp.com \
--cc=linux-nfs@vger.kernel.org \
--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