Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp287622pxj; Tue, 18 May 2021 03:29:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw14Vqgt0Xq0BNpoEYC91Xs/5YzI+5Sztp8TIdDws8JBRdw9bfDXoujOESVOcD8rIUaF75v X-Received: by 2002:a17:906:914d:: with SMTP id y13mr5244931ejw.489.1621333753136; Tue, 18 May 2021 03:29:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621333753; cv=none; d=google.com; s=arc-20160816; b=gXkkf38WVnRaaQLubyVpFreu7bfw1ngigYEOSSPLku+L55032ge5ubpE5sHLXUv2Ek ijbkU3nHUQWqp2kspMzLUukUEMY4ScChv0hNRiLJB+vBh26Cg3DdMAx9euy2Ajvgxdv4 hAy2V8BAtO4Rao67UOs7cyyVWrgDu1wkVejuJgOGrvmAgx7/+6bgU3KbtzKGUjL04GsF pk8luNR0g4Nia5Z0e7NahL+4UQ61cLLiIWEcZgLNlnVeYN1oo+o0fRwL6jmLgSjinXBs T6PVmj3+FtfIYtLqEF9A4LFBi3SgqEboe4PXmMlcIZmfE8vTbXIBgXNPp1JjiaPBOhwK gVhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=imXOZLvhba/DSbhUiCG0U+4+C8kQYC2jQq+PwEl1zN8=; b=QR0ThRtdnl6tdoetoaMQC6wk0/XHqMFO7wu43BBnibQ1+ejMqtaovtPg+n49VRipw6 pbXvoWJK69lSazP3jW3/JEM9OByC+B380P8jH1KVcN6fvXOzLqxyQr2s8t9m871eXn03 5CxodNyh1+hAgNg8319VM9/3QdI8kzJMKJMuxVs9q9sEn5pzyQobfR7EA65JPQ7GL3j6 SClfsOTrbdc5ug4RsSwOnQIa+KNf3CA8QQAGWN9YUdzTMZ1hNe9uNSfHxWzH9Jw89vBF ygtCJY/1pH4fKwu+F0CHMpLHN0K7MDjCV1bFHfmHj54KXnOAI/SZ98leANhxjO75GAIq qf6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="Hg+P/BDf"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m9si20872042ejj.645.2021.05.18.03.28.48; Tue, 18 May 2021 03:29:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="Hg+P/BDf"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243537AbhEQPOS (ORCPT + 99 others); Mon, 17 May 2021 11:14:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:45488 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241151AbhEQPEG (ORCPT ); Mon, 17 May 2021 11:04:06 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id B432961A1D; Mon, 17 May 2021 14:28:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1621261693; bh=CIQG/ufvHpu5ZW5WhA8taivRepwav4zHcs0XSWWSKx8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Hg+P/BDf4IIWBWbIvIoLRMbhaqAZ9Cev5T7DYF5uzxxSXiGaJ6+TKlpaHXT7BIeua tW8IUUwcK6fwfd6FMWGq6GoEMoRSy/stmtjTuERiu0/dqYsdX2WRpYV77wrM51g9ap 5OEuDmtzn5yjL4ciQzljNAj4J/aIDuCClkX7so9o= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Trond Myklebust , Sasha Levin Subject: [PATCH 5.11 151/329] NFSv4.x: Dont return NFS4ERR_NOMATCHING_LAYOUT if were unmounting Date: Mon, 17 May 2021 16:01:02 +0200 Message-Id: <20210517140307.217897713@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210517140302.043055203@linuxfoundation.org> References: <20210517140302.043055203@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Trond Myklebust [ Upstream commit 8926cc8302819be9e67f70409ed001ecb2c924a9 ] If the NFS super block is being unmounted, then we currently may end up telling the server that we've forgotten the layout while it is actually still in use by the client. In that case, just assume that the client will soon return the layout anyway, and so return NFS4ERR_DELAY in response to the layout recall. Fixes: 58ac3e59235f ("NFSv4/pnfs: Clean up nfs_layout_find_inode()") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin --- fs/nfs/callback_proc.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/fs/nfs/callback_proc.c b/fs/nfs/callback_proc.c index f7786e00a6a7..ed9d580826f5 100644 --- a/fs/nfs/callback_proc.c +++ b/fs/nfs/callback_proc.c @@ -137,12 +137,12 @@ static struct inode *nfs_layout_find_inode_by_stateid(struct nfs_client *clp, list_for_each_entry_rcu(lo, &server->layouts, plh_layouts) { if (!pnfs_layout_is_valid(lo)) continue; - if (stateid != NULL && - !nfs4_stateid_match_other(stateid, &lo->plh_stateid)) + if (!nfs4_stateid_match_other(stateid, &lo->plh_stateid)) continue; - if (!nfs_sb_active(server->super)) - continue; - inode = igrab(lo->plh_inode); + if (nfs_sb_active(server->super)) + inode = igrab(lo->plh_inode); + else + inode = ERR_PTR(-EAGAIN); rcu_read_unlock(); if (inode) return inode; @@ -176,9 +176,10 @@ static struct inode *nfs_layout_find_inode_by_fh(struct nfs_client *clp, continue; if (nfsi->layout != lo) continue; - if (!nfs_sb_active(server->super)) - continue; - inode = igrab(lo->plh_inode); + if (nfs_sb_active(server->super)) + inode = igrab(lo->plh_inode); + else + inode = ERR_PTR(-EAGAIN); rcu_read_unlock(); if (inode) return inode; -- 2.30.2