Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2493972imm; Mon, 24 Sep 2018 05:26:48 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZ/3OHmTaG0jNEUcdt/M0ApW3PXlYjGPq6loZzVJ+OnxNeiCBADSUHmzoJvl4xWM7wOfzwn X-Received: by 2002:a62:3241:: with SMTP id y62-v6mr10197188pfy.4.1537792008595; Mon, 24 Sep 2018 05:26:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537792008; cv=none; d=google.com; s=arc-20160816; b=K+yprDS01M/HEKmdKdghziSokCMa+O7hA/DYhOpJe4PNsLGErZrh5zbxo0UD/r6Brj HilZpt85xxP9b5P4a48pBMar/JdTw4h/l4K+PqjiyZX76RZxiKC+JvLSR/NoTZ3QSHZ+ 98B1OcpMoKm4ddV5Y/QNeh0OxSEFE4J68Ti9LoE94tsGoYeEgqF3UHLmkVr71i7DTRRM Ch9KmyMKNZkmPTfccta5gCYNEdxQiSBAV0kLyMzGjizo7sBi3QCFMLPlveaSf+dQU0iU amub0Mzgcco6eJyoG8eGkEsA9Zg6AGSMNIeBWZGvvQ9Aw5tKIJzcntMPYyrd32PayhMF fhUA== 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=EEk+iq2riyi24av+RPf0ogvp7mzu5ZTUaFPBEzuRiM8=; b=L9Ak2ZR/MSbLscuIHQQNTOqg3yAq7g4IVfbk0wcqm3I6G9xoL19opwv5IK1DL0HWFR TkaNEWclO49LvuPXC5i/kfNKOeQ8r9MENaPDKAmRHjMXNkYxBmJcaCdCwmRA6zqFL7fQ YffyZBUNhr8poJi4X4s6Tx1vXDNQF6e1cNxrV6iclCokKFBWYRF4VvvOgtIbuAsU0M0f LEXgShRQaSUpSa70CMe5H/pOUXdVI+oO/OnfroTIGt1jzg/ELW6MVSGFok4qke3WG3qL XutWftYd1sBsVnFF57Z/lI3xNqJDp8YjAy00NJpJvZfFWcVdaMxo83maYrlBUwN8rBzv Ir+w== 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.26.33; Mon, 24 Sep 2018 05:26:48 -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 S1732763AbeIXS0J (ORCPT + 99 others); Mon, 24 Sep 2018 14:26:09 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:56764 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731873AbeIXS0I (ORCPT ); Mon, 24 Sep 2018 14:26:08 -0400 Received: from localhost (ip-213-127-77-73.ip.prioritytelecom.net [213.127.77.73]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 8440F1094; Mon, 24 Sep 2018 12:24:15 +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.14 106/173] NFSv4.1 fix infinite loop on I/O. Date: Mon, 24 Sep 2018 13:52:20 +0200 Message-Id: <20180924113123.866955895@linuxfoundation.org> X-Mailer: git-send-email 2.19.0 In-Reply-To: <20180924113114.334025954@linuxfoundation.org> References: <20180924113114.334025954@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.14-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 @@ -2533,14 +2533,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 @@ -1354,6 +1354,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);