Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2476019imm; Mon, 24 Sep 2018 05:09:21 -0700 (PDT) X-Google-Smtp-Source: ACcGV63i3mLfAMAYGaNpzbVByTo2/8U3w4+WZmnxpysDG/DaHIbG66uxB+aVYt1YGEdiWCmoHy5Z X-Received: by 2002:a63:4826:: with SMTP id v38-v6mr9336476pga.379.1537790961139; Mon, 24 Sep 2018 05:09:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537790961; cv=none; d=google.com; s=arc-20160816; b=Zz+QfudABVhpBT9wz9N/I32syOTlyfR8VZiTtXa6YRwAF8lc5tkImu1BBcwZR4qdTI hEWZz6cyBPYaTqcbvRqZL7TR+PzMsQ1VRKjD8Xx/06u6wJV8v1RzAnUH5FJQqPP6/reO GqchizxLtrIzF4YWbh146jDJdhqHX8DDTXxCAqhKWWk5/fyqOQ4jJy/D2Ebj52jaijsn DiSb1YXdkIbJUMK8DvrYj698zStS8KyfI3utt1RquoMXoGrzJclAHL+ocAVDm991dKFs 7yNVm/UuYzhrlwn/4F2KZ0tezaAMJi4yFxlJ1HZ0AZxomsKRkay78EbIoN8VkDyC0wZI /GPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from; bh=Jpram0DMi4Ab5+9eLoDhSQfBt7J0pSBFhkHoFlnmNj8=; b=IcU4Cdr1Drbm7r2ss0y3pweiUqWQI1UWmw/JbLeAmZ2Xrz2AkFVkn6XLYBmO0wS4rr Xr0oOaCm1C5sLWuOOFi4wXCSONcvHSHS279Mc9uQnSDsc1qhC3pr6EDp2jkcb1Ylt4E9 x5VSMPaPIVUoUSKkVwxlxfb1RGfAFTzrtkRwcLcCFTEqdtI9cLgtT8w39DZPkxPpQAGq allpBCdwrW62rquh/qBkwARDUdXV81SwUoGKv6EB9ng2iSw+L4iPG+HvpP51w07EFsKj fnZR6Z6ZXEeJUCTcGnSENuZmuV702BeXC97b6mHyTlLA/QouvTnfv81jHSqguj5e6Y7A MwtA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x3-v6si14619086pgj.425.2018.09.24.05.09.06; Mon, 24 Sep 2018 05:09:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731134AbeIXSIN (ORCPT + 99 others); Mon, 24 Sep 2018 14:08:13 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:54088 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729828AbeIXSIN (ORCPT ); Mon, 24 Sep 2018 14:08:13 -0400 Received: from localhost (ip-213-127-77-73.ip.prioritytelecom.net [213.127.77.73]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id E67EE1080; Mon, 24 Sep 2018 12:06:24 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Trond Myklebust , Anna Schumaker Subject: [PATCH 4.9 072/111] NFSv4.1 fix infinite loop on I/O. Date: Mon, 24 Sep 2018 13:52:39 +0200 Message-Id: <20180924113112.131758388@linuxfoundation.org> X-Mailer: git-send-email 2.19.0 In-Reply-To: <20180924113103.337261320@linuxfoundation.org> References: <20180924113103.337261320@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Trond Myklebust commit 994b15b983a72e1148a173b61e5b279219bb45ae upstream. The previous fix broke recovery of delegated stateids because it assumes that if we did not mark the delegation as suspect, then the delegation has effectively been revoked, and so it removes that delegation irrespectively of whether or not it is valid and still in use. While this is "mostly harmless" for ordinary I/O, we've seen pNFS fail with LAYOUTGET spinning in an infinite loop while complaining that we're using an invalid stateid (in this case the all-zero stateid). What we rather want to do here is ensure that the delegation is always correctly marked as needing testing when that is the case. So we want to close the loophole offered by nfs4_schedule_stateid_recovery(), which marks the state as needing to be reclaimed, but not the delegation that may be backing it. Fixes: 0e3d3e5df07dc ("NFSv4.1 fix infinite loop on IO BAD_STATEID error") Signed-off-by: Trond Myklebust Cc: stable@vger.kernel.org # v4.11+ Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman --- fs/nfs/nfs4proc.c | 10 +++++++--- fs/nfs/nfs4state.c | 2 ++ 2 files changed, 9 insertions(+), 3 deletions(-) --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -2539,14 +2539,18 @@ static void nfs41_check_delegation_state } nfs4_stateid_copy(&stateid, &delegation->stateid); - if (test_bit(NFS_DELEGATION_REVOKED, &delegation->flags) || - !test_and_clear_bit(NFS_DELEGATION_TEST_EXPIRED, - &delegation->flags)) { + if (test_bit(NFS_DELEGATION_REVOKED, &delegation->flags)) { rcu_read_unlock(); nfs_finish_clear_delegation_stateid(state, &stateid); return; } + if (!test_and_clear_bit(NFS_DELEGATION_TEST_EXPIRED, + &delegation->flags)) { + rcu_read_unlock(); + return; + } + cred = get_rpccred(delegation->cred); rcu_read_unlock(); status = nfs41_test_and_free_expired_stateid(server, &stateid, cred); --- a/fs/nfs/nfs4state.c +++ b/fs/nfs/nfs4state.c @@ -1336,6 +1336,8 @@ int nfs4_schedule_stateid_recovery(const if (!nfs4_state_mark_reclaim_nograce(clp, state)) return -EBADF; + nfs_inode_find_delegation_state_and_recover(state->inode, + &state->stateid); dprintk("%s: scheduling stateid recovery for server %s\n", __func__, clp->cl_hostname); nfs4_schedule_state_manager(clp);