From: NeilBrown <neilb@suse.com>
To: Trond Myklebust <trond.myklebust@primarydata.com>,
Anna Schumaker <anna.schumaker@netapp.com>,
Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH/RFC] NFSv4: don't let hanging mounts block other mounts
Date: Wed, 24 May 2017 09:27:55 +1000 [thread overview]
Message-ID: <87vaori26c.fsf@notabene.neil.brown.name> (raw)
[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]
If you try an NFSv4 mount from an inaccessible server, it will hang as
you would expect.
If you then try an NFSv4 mount from a different accessible server,
it will also hang. This is not expected.
The second mount is blocked in
nfs4_init_client()
-> nfs4_discover_server_trunking()
-> nfs40_discover_server_trunking()
-> nfs40_walk_client_list()
-> nfs4_match_client()
-> nfs_wait_client_init_complete()
It is waiting for the first mount to complete so that it can then
see if the two servers are really one and the same.
It is not necessary to wait here when an nfs_client cl_cons_state is
NFS_CS_INITING. Such a client will, after changing cl_cons_state, call
nfs4_discover_server_trunking() itself. So if the current client just
skips those clients, trunking will still be discovered if necessary.
I am unsure of situation with NFS_CS_SESSION_INITING, but I suspect
that the comment "Wait for CREATE_SESSION to finish" implies that
it is only clients in NFS_CS_SESSION_INITING that need to be waited for.
Signed-off-by: NeilBrown <neilb@suse.com>
---
fs/nfs/nfs4client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
index 692a7a8bfc7a..386901dfdca7 100644
--- a/fs/nfs/nfs4client.c
+++ b/fs/nfs/nfs4client.c
@@ -481,7 +481,7 @@ static int nfs4_match_client(struct nfs_client *pos, struct nfs_client *new,
* remaining fields in "pos", especially the client
* ID and serverowner fields. Wait for CREATE_SESSION
* to finish. */
- if (pos->cl_cons_state > NFS_CS_READY) {
+ if (pos->cl_cons_state == NFS_CS_SESSION_INITING) {
atomic_inc(&pos->cl_count);
spin_unlock(&nn->nfs_client_lock);
--
2.12.2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
reply other threads:[~2017-05-23 23:28 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=87vaori26c.fsf@notabene.neil.brown.name \
--to=neilb@suse.com \
--cc=anna.schumaker@netapp.com \
--cc=chuck.lever@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@primarydata.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).