All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Donald Buczek <buczek@molgen.mpg.de>
Cc: linux-nfs@vger.kernel.org, it+nfs@molgen.mpg.de
Subject: [PATCH] Revert "nfsd4: return default lease period"
Date: Thu, 14 Feb 2019 12:56:55 -0500	[thread overview]
Message-ID: <20190214175655.GA9216@fieldses.org> (raw)
In-Reply-To: <20190208020322.GA9482@fieldses.org>

From: "J. Bruce Fields" <bfields@redhat.com>

This reverts commit d6ebf5088f09472c1136cd506bdc27034a6763f8.

I forgot that the kernel's default lease period should never be
decreased!

After a kernel upgrade, the kernel has no way of knowing on its own what
the previous lease time was.  Unless userspace tells it otherwise, it
will assume the previous lease period was the same.

So if we decrease this value in a kernel upgrade, we end up enforcing a
grace period that's too short, and clients will fail to reclaim state in
time.  Symptoms may include EIO and log messages like "NFS:
nfs4_reclaim_open_state: Lock reclaim failed!"

There was no real justification for the lease period decrease anyway.

Reported-by: Donald Buczek <buczek@molgen.mpg.de>
Fixes: d6ebf5088f09 "nfsd4: return default lease period"
Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
---
 fs/nfsd/nfsctl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

On Thu, Feb 07, 2019 at 09:03:22PM -0500, bfields wrote:
> On Thu, Feb 07, 2019 at 12:48:41PM +0100, Donald Buczek wrote:
> > As an experiment, I've also restarted a server with the lease time
> > decrement from 90 to 45 seconds, but the grace period fixed to
> > 90 seconds. Now the client got NFS4ERR_STALE_CLIENTID  but still did
> > not query the server for a new lease_time and continued to send RENEWs
> > in 60 second intervals.

So this doesn't fix that client bug, but it does fix the server.

diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
index b33f9785b756..72a7681f4046 100644
--- a/fs/nfsd/nfsctl.c
+++ b/fs/nfsd/nfsctl.c
@@ -1239,8 +1239,8 @@ static __net_init int nfsd_init_net(struct net *net)
 	retval = nfsd_idmap_init(net);
 	if (retval)
 		goto out_idmap_error;
-	nn->nfsd4_lease = 45;	/* default lease time */
-	nn->nfsd4_grace = 45;
+	nn->nfsd4_lease = 90;	/* default lease time */
+	nn->nfsd4_grace = 90;
 	nn->somebody_reclaimed = false;
 	nn->clverifier_counter = prandom_u32();
 	nn->clientid_counter = prandom_u32();
-- 
2.20.1


      reply	other threads:[~2019-02-14 17:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-07 11:48 4.0 client and server restart with decreased lease time Donald Buczek
2019-02-08  2:03 ` J. Bruce Fields
2019-02-14 17:56   ` J. Bruce Fields [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=20190214175655.GA9216@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=buczek@molgen.mpg.de \
    --cc=it+nfs@molgen.mpg.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.