Received: by 2002:a05:6520:4d:b0:139:a872:a4c9 with SMTP id i13csp2566219lkm; Mon, 20 Sep 2021 18:53:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyiA960Z5seTfrEq+bB75iDyx8GelAuLir3t36vPw2wn/i7JXsYKoO7KQRKjrO4oBqiZBMQ X-Received: by 2002:a05:6638:35ac:: with SMTP id v44mr21513276jal.48.1632189181344; Mon, 20 Sep 2021 18:53:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632189181; cv=none; d=google.com; s=arc-20160816; b=M9sKefuX+CZUBmG5bHALFXNUw67zlyz5brXDVTFNFmkZk/nOfLk+zkNXFGUB2xPqWl UdRgFDk6SQGtN8MMmAEXmZZ8T/IjhByF+ePqgONLjVjd95iLueCrarwppApVs7lL0Mfu t5i1z53QHRmsNfmvIr818+UVzgvZgmmh5APnO2DrynXFaq0C1RRbQHGAPBFr8ZzNWO+d La7Scjr6Sl9gq7p+BoIR2CvjfbP4qd2XoBsTvYT+CrxjjxSx2M3sqOjuJyA/XRcGilhQ lWkhppytRPJIlktmcPvolLOCxTAH3+RAgpTPgKaEE2ecMAo21U9QBzumk7DZOmQ1vjfd 5HdQ== 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=VwzHqauDT7Tcp19WfyfMVc/nevt5RaUtQ2wkcprGgkM=; b=EKsfO0j7GANWSkERuBn3/NFmD51gtE/F052mwWA59+UsZNWuOSG6fcbC0bxDaijfaZ RRX1NSkhUxnGgJh5eT8cxNLRoMpI34Zpg3B7u0MJn53YD934TGn0lVJ4oihYA5A9u9nI JZLntZ6gKLitkZigZPirqDfvZjmqu8+k3noVQ5NAcl48NjMzQWfjqGaZ1KWaOv7zmTLp wpo0F2dNJtvoJybHEkOGXRtrv3TX0w/UOAE5HC3yYN4jeVUxxLfTCjBHNPFBaj69DOUX GzGFcULdQlI5CkP3TA1E6tMYvjnG8DzyWDMsSfL2vfburjF/0Yd7fQl8sHWCBC9t+nHN DSPQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=K0s2G9n5; 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 p8si15153177ilo.5.2021.09.20.18.52.45; Mon, 20 Sep 2021 18:53:01 -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=K0s2G9n5; 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 S1351237AbhITSPu (ORCPT + 99 others); Mon, 20 Sep 2021 14:15:50 -0400 Received: from mail.kernel.org ([198.145.29.99]:35786 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359805AbhITSKT (ORCPT ); Mon, 20 Sep 2021 14:10:19 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id EB65F63272; Mon, 20 Sep 2021 17:20:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1632158410; bh=6jIf8nZRuMRADKxZaJGLyn042j9YUFiBbmz7K9UfpwU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=K0s2G9n5uWRCazKuzez9u9Y3k0tcvKDCt8/5xcffasdC/wIQoSKrDiIJyjeessPo9 haWpe/S3E2MaWSMBu596ry09JYCd2v3ebOeyNSvSChYcO9FkDxKBlq9I9iqSZIEFtj A8DSPNRfYT4M2UuBoxBu2lOhK/ibxHna9McCrWJY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Bob Peterson , Sasha Levin Subject: [PATCH 5.4 143/260] gfs2: Dont call dlm after protocol is unmounted Date: Mon, 20 Sep 2021 18:42:41 +0200 Message-Id: <20210920163935.978017060@linuxfoundation.org> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20210920163931.123590023@linuxfoundation.org> References: <20210920163931.123590023@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: Bob Peterson [ Upstream commit d1340f80f0b8066321b499a376780da00560e857 ] In the gfs2 withdraw sequence, the dlm protocol is unmounted with a call to lm_unmount. After a withdraw, users are allowed to unmount the withdrawn file system. But at that point we may still have glocks left over that we need to free via unmount's call to gfs2_gl_hash_clear. These glocks may have never been completed because of whatever problem caused the withdraw (IO errors or whatever). Before this patch, function gdlm_put_lock would still try to call into dlm to unlock these leftover glocks, which resulted in dlm returning -EINVAL because the lock space was abandoned. These glocks were never freed because there was no mechanism after that to free them. This patch adds a check to gdlm_put_lock to see if the locking protocol was inactive (DFL_UNMOUNT flag) and if so, free the glock and not make the invalid call into dlm. I could have combined this "if" with the one that follows, related to leftover glock LVBs, but I felt the code was more readable with its own if clause. Signed-off-by: Bob Peterson Signed-off-by: Sasha Levin --- fs/gfs2/lock_dlm.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/gfs2/lock_dlm.c b/fs/gfs2/lock_dlm.c index 72dec177b349..94c290a333a0 100644 --- a/fs/gfs2/lock_dlm.c +++ b/fs/gfs2/lock_dlm.c @@ -292,6 +292,11 @@ static void gdlm_put_lock(struct gfs2_glock *gl) gfs2_sbstats_inc(gl, GFS2_LKS_DCOUNT); gfs2_update_request_times(gl); + /* don't want to call dlm if we've unmounted the lock protocol */ + if (test_bit(DFL_UNMOUNT, &ls->ls_recover_flags)) { + gfs2_glock_free(gl); + return; + } /* don't want to skip dlm_unlock writing the lvb when lock has one */ if (test_bit(SDF_SKIP_DLM_UNLOCK, &sdp->sd_flags) && -- 2.30.2