From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Date: Thu, 9 Apr 2020 23:51:17 -0400 Subject: [Cluster-devel] [PATCH AUTOSEL 4.4 4/8] gfs2: Don't demote a glock until its revokes are written In-Reply-To: <20200410035122.10065-1-sashal@kernel.org> References: <20200410035122.10065-1-sashal@kernel.org> Message-ID: <20200410035122.10065-4-sashal@kernel.org> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Bob Peterson [ Upstream commit df5db5f9ee112e76b5202fbc331f990a0fc316d6 ] Before this patch, run_queue would demote glocks based on whether there are any more holders. But if the glock has pending revokes that haven't been written to the media, giving up the glock might end in file system corruption if the revokes never get written due to io errors, node crashes and fences, etc. In that case, another node will replay the metadata blocks associated with the glock, but because the revoke was never written, it could replay that block even though the glock had since been granted to another node who might have made changes. This patch changes the logic in run_queue so that it never demotes a glock until its count of pending revokes reaches zero. Signed-off-by: Bob Peterson Reviewed-by: Andreas Gruenbacher Signed-off-by: Sasha Levin --- fs/gfs2/glock.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c index 1eb737c466ddc..f80ffccb03160 100644 --- a/fs/gfs2/glock.c +++ b/fs/gfs2/glock.c @@ -541,6 +541,9 @@ __acquires(&gl->gl_lockref.lock) goto out_unlock; if (nonblock) goto out_sched; + smp_mb(); + if (atomic_read(&gl->gl_revokes) != 0) + goto out_sched; set_bit(GLF_DEMOTE_IN_PROGRESS, &gl->gl_flags); GLOCK_BUG_ON(gl, gl->gl_demote_state == LM_ST_EXCLUSIVE); gl->gl_target = gl->gl_demote_state; -- 2.20.1 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78F2BC2D0EC for ; Fri, 10 Apr 2020 03:51:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4423320BED for ; Fri, 10 Apr 2020 03:51:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586490694; bh=QKMcaEVYytCyf1hqsXW7L2gDGVX8IfnY0Ttlq6wcg+E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=BEESb/B6maBE3D1hsCP20ppP81LRmClJqeJ6I7Ayw30X5+HEpjAZEmfLLNg0Gcol+ qna6NDogaXI4bfTOuxsB1EP4Iu5QhycPEo2dzN6DJ7jdgNYJ4e12UB05wkzW452E57 gop6trpFoJqbO3WCRkJE2jW5s98ZtqnpJ8evCDho= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729235AbgDJDvc (ORCPT ); Thu, 9 Apr 2020 23:51:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:36762 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726942AbgDJDv0 (ORCPT ); Thu, 9 Apr 2020 23:51:26 -0400 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4048E2173E; Fri, 10 Apr 2020 03:51:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586490686; bh=QKMcaEVYytCyf1hqsXW7L2gDGVX8IfnY0Ttlq6wcg+E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QBgSpQp4I0o9juh3XSSdDt9Ze8zzZXyrX5LgUIKqHSlN0+K4K9xBM5oa3AzAWR9hQ SZEP+b4Wl+nz4LY2Egux+0agpkugvPxLGqeaWAi8MUE0l9eUdcf1IRNMLpZU6dzRKN QBukgeEg2fvc9/AjUDej8tgQ70p0wLrwSKUdGR7Y= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bob Peterson , Andreas Gruenbacher , Sasha Levin , cluster-devel@redhat.com Subject: [PATCH AUTOSEL 4.4 4/8] gfs2: Don't demote a glock until its revokes are written Date: Thu, 9 Apr 2020 23:51:17 -0400 Message-Id: <20200410035122.10065-4-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200410035122.10065-1-sashal@kernel.org> References: <20200410035122.10065-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Bob Peterson [ Upstream commit df5db5f9ee112e76b5202fbc331f990a0fc316d6 ] Before this patch, run_queue would demote glocks based on whether there are any more holders. But if the glock has pending revokes that haven't been written to the media, giving up the glock might end in file system corruption if the revokes never get written due to io errors, node crashes and fences, etc. In that case, another node will replay the metadata blocks associated with the glock, but because the revoke was never written, it could replay that block even though the glock had since been granted to another node who might have made changes. This patch changes the logic in run_queue so that it never demotes a glock until its count of pending revokes reaches zero. Signed-off-by: Bob Peterson Reviewed-by: Andreas Gruenbacher Signed-off-by: Sasha Levin --- fs/gfs2/glock.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c index 1eb737c466ddc..f80ffccb03160 100644 --- a/fs/gfs2/glock.c +++ b/fs/gfs2/glock.c @@ -541,6 +541,9 @@ __acquires(&gl->gl_lockref.lock) goto out_unlock; if (nonblock) goto out_sched; + smp_mb(); + if (atomic_read(&gl->gl_revokes) != 0) + goto out_sched; set_bit(GLF_DEMOTE_IN_PROGRESS, &gl->gl_flags); GLOCK_BUG_ON(gl, gl->gl_demote_state == LM_ST_EXCLUSIVE); gl->gl_target = gl->gl_demote_state; -- 2.20.1