From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:58658 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1945987AbcHRJ7H (ORCPT ); Thu, 18 Aug 2016 05:59:07 -0400 Subject: Patch "pNFS: Handle NFS4ERR_RECALLCONFLICT correctly in LAYOUTGET" has been added to the 4.7-stable tree To: trond.myklebust@primarydata.com, gregkh@linuxfoundation.org, jlayton@redhat.com Cc: , From: Date: Thu, 18 Aug 2016 11:58:55 +0200 Message-ID: <147151433424107@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: This is a note to let you know that I've just added the patch titled pNFS: Handle NFS4ERR_RECALLCONFLICT correctly in LAYOUTGET to the 4.7-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: pnfs-handle-nfs4err_recallconflict-correctly-in-layoutget.patch and it can be found in the queue-4.7 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >>From 66b53f325876703b7ab815c482cd104609f8772c Mon Sep 17 00:00:00 2001 From: Trond Myklebust Date: Thu, 14 Jul 2016 14:28:31 -0400 Subject: pNFS: Handle NFS4ERR_RECALLCONFLICT correctly in LAYOUTGET From: Trond Myklebust commit 66b53f325876703b7ab815c482cd104609f8772c upstream. Instead of giving up altogether and falling back to doing I/O through the MDS, which may make the situation worse, wait for 2 lease periods for the callback to resolve itself, and then try destroying the existing layout. Only if this was an attempt at getting a first layout, do we give up altogether, as the server is clearly crazy. Fixes: 183d9e7b112aa ("pnfs: rework LAYOUTGET retry handling") Signed-off-by: Trond Myklebust Reviewed-by: Jeff Layton Signed-off-by: Greg Kroah-Hartman --- fs/nfs/pnfs.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) --- a/fs/nfs/pnfs.c +++ b/fs/nfs/pnfs.c @@ -1505,7 +1505,7 @@ pnfs_update_layout(struct inode *ino, struct pnfs_layout_segment *lseg = NULL; nfs4_stateid stateid; long timeout = 0; - unsigned long giveup = jiffies + rpc_get_timeout(server->client); + unsigned long giveup = jiffies + (clp->cl_lease_time << 1); bool first; if (!pnfs_enabled_sb(NFS_SERVER(ino))) { @@ -1649,9 +1649,18 @@ lookup_again: if (IS_ERR(lseg)) { switch(PTR_ERR(lseg)) { case -EBUSY: - case -ERECALLCONFLICT: if (time_after(jiffies, giveup)) lseg = NULL; + break; + case -ERECALLCONFLICT: + /* Huh? We hold no layouts, how is there a recall? */ + if (first) { + lseg = NULL; + break; + } + /* Destroy the existing layout and start over */ + if (time_after(jiffies, giveup)) + pnfs_destroy_layout(NFS_I(ino)); /* Fallthrough */ case -EAGAIN: break; Patches currently in stable-queue which might be from trond.myklebust@primarydata.com are queue-4.7/nfs-don-t-create-zero-length-requests.patch queue-4.7/pnfs-separate-handling-of-nfs4err_layouttrylater-and-recallconflict.patch queue-4.7/pnfs-handle-nfs4err_recallconflict-correctly-in-layoutget.patch queue-4.7/pnfs-fix-layoutget-handling-of-nfs4err_bad_stateid-and-nfs4err_expired.patch queue-4.7/pnfs-fix-post-layoutget-error-handling-in-pnfs_update_layout.patch