linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: linux-nfs@vger.kernel.org
Subject: kernel not recovering from statd port change
Date: Thu, 21 Aug 2014 17:34:21 -0400	[thread overview]
Message-ID: <20140821213421.GA5474@fieldses.org> (raw)

While testing server restart somebody noticed that knfsd can't recover
from statd restarting with a new port.

>From only a very quick skim of the code it looked like creating the nsm
client with RPC_CLNT_CREATE_AUTOBIND should cause us to call rpcbind
again on connection failures, but that doesn't seem to be working.

Any ideas?  I'll keep looking....

--b.

commit 2c9fb5570fe2
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Wed Aug 20 17:21:32 2014 -0400

    lockd: allow rebinding to statd
    
    During normal operation statd isn't restarted, but it may be if, for
    example, the server is shut down and restarted to simulate a shutdown or
    perform some kind of failover.  In that case the kernel may need to
    query rpcbind again to get statd's new port number.
    
    Symptoms were locking failures after a manual server restart (without
    rebooting the machine), and loopback network traces showing the new
    kernel nfsd attempting to contact statd at its old port number.
    
    This was probably introduced by cb7323fffa85, which first allowed
    reusing the statd rpc client, but it looks like a reference count may
    typically have prevented any symptoms until e498daa81295 "LOCKD: Clear
    ln->nsm_clnt only when ln->nsm_users is zero".
    
    Fixes: cb7323fffa85 "lockd: create and use per-net NSM RPC clients on MON/UNMON requests"
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

diff --git a/fs/lockd/mon.c b/fs/lockd/mon.c
index 1812f026960c..3bce1d318435 100644
--- a/fs/lockd/mon.c
+++ b/fs/lockd/mon.c
@@ -80,7 +80,8 @@ static struct rpc_clnt *nsm_create(struct net *net)
 		.program		= &nsm_program,
 		.version		= NSM_VERSION,
 		.authflavor		= RPC_AUTH_NULL,
-		.flags			= RPC_CLNT_CREATE_NOPING,
+		.flags			= RPC_CLNT_CREATE_NOPING|
+			                  RPC_CLNT_CREATE_AUTOBIND,
 	};
 
 	return rpc_create(&args);

             reply	other threads:[~2014-08-21 21:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-21 21:34 J. Bruce Fields [this message]
2014-09-04 20:42 ` kernel not recovering from statd port change Colin Hudler
2014-09-04 21:01 ` Trond Myklebust

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=20140821213421.GA5474@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    /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).