From patchwork Thu Jul 14 22:58:34 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Trond Myklebust X-Patchwork-Id: 9230867 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 38F4660868 for ; Thu, 14 Jul 2016 22:59:11 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2CDBD2818B for ; Thu, 14 Jul 2016 22:59:11 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1D95F28325; Thu, 14 Jul 2016 22:59:11 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C3986281A7 for ; Thu, 14 Jul 2016 22:59:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751976AbcGNW7I (ORCPT ); Thu, 14 Jul 2016 18:59:08 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:33458 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751279AbcGNW7G (ORCPT ); Thu, 14 Jul 2016 18:59:06 -0400 Received: by mail-it0-f67.google.com with SMTP id d65so310387ith.0 for ; Thu, 14 Jul 2016 15:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:date:message-id:in-reply-to:references; bh=n4GSJPgxlu1nwM9KlBrau+E1vdQURobM8YE8EJ4Eckc=; b=It5UqqH+SNlKi1fBe4WtDDw0EchU9NOu0L+hgihwiRWf3suvIWSAoDGuYfHYLcYXQp Kn76nsyLweek5XVlniT6GOXcCdnYAplw5/imahLTP7TRKOC0xdKtftJaQy0aoaS/yHWP +YuDGrOG/fBbolXIu2Z1q7vrrj4ULzTEpdCV1YRrfhTSiXpaERVYyn9g2rFHEsQxq9bO lcJHHXUUITQTFRz/d+fJqpDkvY77sDBy8NAcxF/ZW1DdAg1S34CC3b7+WoKVIfxWaOQW teZQE6POHLGrUOiXSUadHvodXlaNj+KX4LlynD9ivjsi6gFxs2W9+Q2JPJDFSfB/ES3a w4kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:subject:date:message-id :in-reply-to:references; bh=n4GSJPgxlu1nwM9KlBrau+E1vdQURobM8YE8EJ4Eckc=; b=BuCPyDBssJBhP+MNuJOwNrfN8MP0SV9k7jFA/1/yJSJdkZ/UQZrP6DLRaw4P+Bf5un /6yOtvBh3JphTHMaH2p3ccbuiG6OGFmXIvoT2rO9QQSRqe07oBp69VWwSNRoxhvoChJ3 f8ujPJIWGEAPuxZlijH5sQBmg8opcI5mV8j/DTEyXZg8A/1CpiZ0CJbfHDgz2F8OhiwW EXc6utlvBIbBQkwiAXzfupMaSCHSKSzmwyjGtGgvCexCNyFCO12HyFm2FzB1NlhTpkDp K171ZbIkwRDMP7Tlhg+2nU8yrQT8pMxElhW5IPunQwX/7sNIqnDxJ+q6fj9lDKXC0xdT HPyQ== X-Gm-Message-State: ALyK8tLAMvHQHV6C1L/DLFiTsJgJ1Mvq9ehSg12JGtl7H5N9t4gMu22Jdqrk1LDqDefdiQ== X-Received: by 10.36.17.131 with SMTP id 125mr18818385itf.94.1468537145727; Thu, 14 Jul 2016 15:59:05 -0700 (PDT) Received: from leira.trondhjem.org.localdomain ([50.108.12.87]) by smtp.gmail.com with ESMTPSA id m203sm2183353iom.21.2016.07.14.15.59.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jul 2016 15:59:05 -0700 (PDT) From: Trond Myklebust To: linux-nfs@vger.kernel.org Subject: [PATCH 3/4] pNFS: Handle NFS4ERR_RECALLCONFLICT correctly in LAYOUTGET Date: Thu, 14 Jul 2016 18:58:34 -0400 Message-Id: <1468537115-65826-3-git-send-email-trond.myklebust@primarydata.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1468537115-65826-2-git-send-email-trond.myklebust@primarydata.com> References: <1468537115-65826-1-git-send-email-trond.myklebust@primarydata.com> <1468537115-65826-2-git-send-email-trond.myklebust@primarydata.com> Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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") Cc: stable@vger.kernel.org # 4.7 Signed-off-by: Trond Myklebust --- fs/nfs/pnfs.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c index b5c1306f63c1..0da9353f0441 100644 --- 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;