Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp442160pxj; Tue, 18 May 2021 06:54:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEDh5qJfLxmb0+2BgBGz8/KfNMXHInDn6v9DZuOK2hZhFEJxxhns5ZBbM9DjC+FPNxZYy1 X-Received: by 2002:a17:906:2dd4:: with SMTP id h20mr6199893eji.131.1621346080094; Tue, 18 May 2021 06:54:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621346080; cv=none; d=google.com; s=arc-20160816; b=ePnkCl8L2iZS/PyKDiPDfxAN4tPcm0cLKEmCKvJ+QRJR8x5h1hND7yqcVMo7QEZbpG bB13VbD8Yi5NQqcLdUaGEtFDvYwF9IoI8qTGB7fUTofUXOplOFgMGyPRVyq+azWz04/p ticIlTOivoy3z0tQFxjT4Hn9I0F9GkXhzkLtVrUNVcZfcJcjc7UF9MZoDeIzLMNufuLH WTa8QKWHTrM+vokjBCw43Dr7348/TPeRxPns5On9JDCD8+RTpzU8lULysaVwpnAH+vsB kS+u3K3voSbZbxi7nrUkD3VfS72D5y3u7ow8wubVxt3dozXi3Q1/wYqFoU4fP9L2ujbt NDNQ== 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=rwZrx7McFJojOOTeHzSSbkHQkD7wi4oegYKXWjoE8hw=; b=msdUBchQ/lspM6ZNcs4FfUJYBMqvrUNRZsZpN9j8+VPyjU3b5wfIUkDaFVYLibX6oA z5nIObPPKvbfthlReSpZpTqMgxd16tltm1n3v7NrTjSZ6vRgplUcnvHbt0qB3hfVz/lE XU3RiMrkJGIuWz9AtTgrn96LGxqNgGIt/eHIM+sZ2ncdFbicdwfzfUfsAgigTHGhqzmX 3bjErhaGW/cOGE8X0TmmYo7d/kI+qS77dcHfxZzhvMsBIccTu9TvyXCXj8JzVqYK626Z z5EgpV8Z4WbSquJzG377rKLUnrLq302pb/vXlyxw/cPXFV8g/mnJQlhl9s0EmLOnKArG zzVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=D8Vjt5nX; 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 k24si16962026ejq.376.2021.05.18.06.54.13; Tue, 18 May 2021 06:54:40 -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=D8Vjt5nX; 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 S244746AbhEQPkk (ORCPT + 99 others); Mon, 17 May 2021 11:40:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:40572 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243448AbhEQP0J (ORCPT ); Mon, 17 May 2021 11:26:09 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 52CC961929; Mon, 17 May 2021 14:36:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1621262177; bh=5IlApkA+vKU9uwIT7nJOHhW1gvuH1JjuqpvzepCNKJA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=D8Vjt5nXcTnp1A7rAisavvEaKgcMgrHDTZpxgQSXDMqG2a0Ns14trKmdXtM2hTVhP xqHjYH+oj8jAeYyRXI84b7bpTw33Oa9s3sB0hwrWcbzdZw0Uj14p2enCvSd/PWCYHm 1m4fgPNN69g61+TiYd3ijtAT8WtdqfFUcmgGGRVU= 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.10 127/289] NFSv4.x: Dont return NFS4ERR_NOMATCHING_LAYOUT if were unmounting Date: Mon, 17 May 2021 16:00:52 +0200 Message-Id: <20210517140309.437019436@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210517140305.140529752@linuxfoundation.org> References: <20210517140305.140529752@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 e61dbc9b86ae..be546ece383f 100644 --- a/fs/nfs/callback_proc.c +++ b/fs/nfs/callback_proc.c @@ -132,12 +132,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; @@ -171,9 +171,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