Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3037957pxj; Mon, 17 May 2021 16:10:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwNnmH8Qg7WHx20KFP9MATXub+1uyRRRKnIC6T7VRAdMZK+6gs6KO+mLO4Mzng/57aJPy8O X-Received: by 2002:a05:6602:1212:: with SMTP id y18mr1936381iot.189.1621293037846; Mon, 17 May 2021 16:10:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621293037; cv=none; d=google.com; s=arc-20160816; b=MnKrkhDpG5RWPnUxX38wEJUwQH6Y7v6QHZJg2wFScAqUPI62ciHo2iW5NaKQbneEqq W9QMkkAtEtoV41wHUh+KkOu7/dtjfwb6bwg4lqsokkxmob3R9vJJX1blfHW6dhaGXkKz RYFCzLd9Dmh/fIXVPfAKgsgEw86PplqxQ0MSzXLs/ZhpNwJVUi6sr5KzWAWXcqWxP3Co Ef3SKBr+l56VVjcIHoLsD7cXQWdwFxK9PwXiiny8HFMZZX1NNRWr3uiXF75YvNLsNM9d ch9qNPv8cjXy6s1KfbotvOs3K/lxp1ombcOO8TBk354GMi0ByzflOUepUmqyhqo7k1Ws 3a/A== 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=Rha5beyYZ6paZ9vudCLxGlrLXKeiMe4xj4FLxrEOEnHvTLXsLXlqyhmXuymTQ3hkwg z2o9iG+cKhN0OUDJWc3tG2qhSLw3YlOrRpvCXXI8s1TpxoMm4wGKrWECn1t/PfSfsdJ5 9uynfWqtFR+NBWs9F3/d3gjWu03gmDrQJa4ITzJ7XQeNZ4SIjomkWQ387DRjeQe0ZR7X UlhfUADfknBO2+omNuZt60Hx8rM/iNPf9aWlo+YCcv4BQtfw1HpP5Z+yD0rmM8+OAF11 lPEHVLJtmEMiDd/slcfdGrzsoeyrpao2qJ9OgNLEFGgxzXzVVDFBTcIiEpT1+y/xVHDs 7o3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=O+ZXsLsR; 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 b14si20649376ilv.52.2021.05.17.16.10.18; Mon, 17 May 2021 16:10:37 -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=O+ZXsLsR; 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 S237172AbhEQOVc (ORCPT + 99 others); Mon, 17 May 2021 10:21:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:35736 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239118AbhEQOSq (ORCPT ); Mon, 17 May 2021 10:18:46 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 940DE61221; Mon, 17 May 2021 14:10:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1621260622; bh=CIQG/ufvHpu5ZW5WhA8taivRepwav4zHcs0XSWWSKx8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=O+ZXsLsRpG/HeZzoCZrnVPAtUD5nk8NGeAu1BluRQOFHNQoLYPF+BPb4wAFV8pU/A p6kvUpkr0yHODuuryZuROHY2b5ywiWY4W7Lwvucsq3TshYvdesaGGrUnI/CNkrO5zR 9XmbTQqSVqachHsjW/4YJPiryCoY5U57R9VHLsRE= 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.12 165/363] NFSv4.x: Dont return NFS4ERR_NOMATCHING_LAYOUT if were unmounting Date: Mon, 17 May 2021 16:00:31 +0200 Message-Id: <20210517140308.183347345@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210517140302.508966430@linuxfoundation.org> References: <20210517140302.508966430@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