Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2509322imm; Mon, 24 Sep 2018 05:40:25 -0700 (PDT) X-Google-Smtp-Source: ACcGV60gillluIQjiplkNsGtGWCxWkyeUs3sky50By/iWcCJLFiCgVfG0gIUKZDfgjk2xxZtr5aZ X-Received: by 2002:a63:1e19:: with SMTP id e25-v6mr1603646pge.44.1537792825786; Mon, 24 Sep 2018 05:40:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537792825; cv=none; d=google.com; s=arc-20160816; b=N+hyQw7zdKc4wfMKB+29Od6sgwEqK9T3G6q303mA6QMc5Cu8MQn1vmQeS9TOO9R1dq HKPHjyAWdm8GzxzOIXUbonPz+Q2WsdnK8WSjN4IstIuO1brv1xNAxZfm6jvNZ06WLzW9 DAj1qveyMbsU/ObhQp1XDcd91dbt5mg8IL1Wmz04B28sounXbyZhA4gAhc2CJ5dwwRSH H14+4Wn0pxM0lxj0m0irUem0HSQf2BvLOodka7vp1+n+Wl6PS1sKIgtJkGIQiKuVzjqB 2Ell97zfsar8mwpySTHC1jqi5CIQhR+HEvmiflGoT6JYvQQaAWy7RswGZlOxDYDpwt8a bSAA== 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=KCxl+K1/XaECNeD1ic7oS81XG6BSy26QB7RHujvOD/8=; b=NEiM4hbCWTK36OfPk2QDWSri5NRLppzef2TN3jMP3sYMlTX/8YdgmQG5AtRXTK8ua8 u0N2gtALT3jCjha0W4LLPn8gKKRBoihEK/4OpB0m++5vzNMGODStggF6fXbg2xOYhFkf QJb7QdNUrZ1flKmsaO0T10HCV24LhTtzYMdlEBfOJegtDMVdC8LiTy3ApwIH33TgZOOI HRfhlYFiQYzsW0qZuPRaFdfZ2TqZy7YSmuxA8yVV/7kjyAlkj2tQf3l93Fi3SUbbEedj qKf3F72pSj9/2/tDmnqgBjlAbl0ob6BPANYkqroZvXRw29x5ZygRlOhs+NL+2Q6/uwoD T+zw== 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 y86-v6si38086866pfi.195.2018.09.24.05.40.10; Mon, 24 Sep 2018 05:40:25 -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 S2388430AbeIXSlH (ORCPT + 99 others); Mon, 24 Sep 2018 14:41:07 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:58814 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729740AbeIXSlG (ORCPT ); Mon, 24 Sep 2018 14:41:06 -0400 Received: from localhost (ip-213-127-77-73.ip.prioritytelecom.net [213.127.77.73]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 9F5CA1098; Mon, 24 Sep 2018 12:39:08 +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.18 143/235] NFSv4.1 fix infinite loop on I/O. Date: Mon, 24 Sep 2018 13:52:09 +0200 Message-Id: <20180924113119.890887073@linuxfoundation.org> X-Mailer: git-send-email 2.19.0 In-Reply-To: <20180924113103.999624566@linuxfoundation.org> References: <20180924113103.999624566@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.18-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 @@ -2642,14 +2642,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 @@ -1390,6 +1390,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);