Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2281009iof; Wed, 8 Jun 2022 01:18:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw0NN5xwS9lfKaHittuOs5eDtCXKbv7RZVQ+WWvOp+TciKFIDr24Th9ZgBWqIfSPy8jx041 X-Received: by 2002:a63:594c:0:b0:3fd:9b8b:863d with SMTP id j12-20020a63594c000000b003fd9b8b863dmr15197796pgm.250.1654676290660; Wed, 08 Jun 2022 01:18:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654676290; cv=none; d=google.com; s=arc-20160816; b=PhlJaIeDNni5RLGXtOIdbvhdOtLYPaAw4tnASJDmzgA53f9oZv90IjBnZfP+5ZtIyW M1em7Ez+AqMSON6h3X7m06g11SBUGz+zW5bo2jhEMrTORVj9IPnQHwfNpaJ9sRWBfzSj keTtdPf5WeTl1/SZPLIJV5FKMOK9lzbmulnWLMWMaLzoUSzuAcHj7o/biuzUoZjUkei8 gW8yTQIxYfr/aTJl34Zu/KRBHdG2dVIJn6P6CGvxJ0VYda2ODVqFTJafiIno81dUzAvO iSk/6HUxU6YotnhPhE4P9M23ty32+V1WzD8ipNmr/7JV+6R5XSrQztBJnJynw4TuVKX0 q8Vw== 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=Y+A6sdPmTyPYf0XEQt4TiRsmhRe7T3bw/4bm9VICnyU=; b=h3yJbAqpP+VVekBw4lHkUCyhZAnXXXls4Xyb1T2U3p6RG3wTrlos9lHOAOdPD4uvcL mPS4L7swGtveGvK5bXx2kHZcChcVopWfoAo+D59Q/nwBEsQksKGFLPo9YbZRxZCl+a4y rFJXw4Xs5ZbSvc2JyHh2w4om0ZI971m9z5OSJWWzXVc2LJ5EpbjC4ZW3+x/JLozf/x62 2AZTzu3MEErbd2CHevPfsmx4FQJmcfBe2pi5RQVImY15/h4417g1JErSxSVwNYLxLv4X UxE24/oo1gyzLDFi8uhTLuhMnelWBYkMtDZSQtCpQ/PiwMKHr8D6OA+iT4lPs7veAuRC IA2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=2Qkh6Maf; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id 28-20020a630a1c000000b003fc695d1439si27347662pgk.387.2022.06.08.01.18.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jun 2022 01:18:10 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=2Qkh6Maf; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 91E173AA9E4; Wed, 8 Jun 2022 00:48:13 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1388481AbiFHB1m (ORCPT + 99 others); Tue, 7 Jun 2022 21:27:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49782 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1382490AbiFGWYC (ORCPT ); Tue, 7 Jun 2022 18:24:02 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F07F226D37B; Tue, 7 Jun 2022 12:22:39 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id F10FB60A1D; Tue, 7 Jun 2022 19:22:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05AF5C385A2; Tue, 7 Jun 2022 19:22:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654629758; bh=+DFhx/+zMYy9AJgFEs5i0jMWEHc2bLU2fzKwpiStgNA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=2Qkh6MafUN658oH/PBRmdKIptxqnb37TVVPiskiOg3wU5x9WgnEwnc8zJ2hbFNW+V 57iTv7w4W9EarY4df/8VAUyaaFXkqMUQHshJp3a6GO2W4zs2eMTWuFcK1+yJeXvLxM woAgunQ9wubFbtKuqGg2vSG/U9Jv9U9/Z1rDG+mM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alexander Aring , David Teigland Subject: [PATCH 5.18 766/879] dlm: fix missing lkb refcount handling Date: Tue, 7 Jun 2022 19:04:44 +0200 Message-Id: <20220607165025.097431083@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220607165002.659942637@linuxfoundation.org> References: <20220607165002.659942637@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Alexander Aring commit 1689c169134f4b5a39156122d799b7dca76d8ddb upstream. We always call hold_lkb(lkb) if we increment lkb->lkb_wait_count. So, we always need to call unhold_lkb(lkb) if we decrement lkb->lkb_wait_count. This patch will add missing unhold_lkb(lkb) if we decrement lkb->lkb_wait_count. In case of setting lkb->lkb_wait_count to zero we need to countdown until reaching zero and call unhold_lkb(lkb). The waiters list unhold_lkb(lkb) can be removed because it's done for the last lkb_wait_count decrement iteration as it's done in _remove_from_waiters(). This issue was discovered by a dlm gfs2 test case which use excessively dlm_unlock(LKF_CANCEL) feature. Probably the lkb->lkb_wait_count value never reached above 1 if this feature isn't used and so it was not discovered before. The testcase ended in a rsb on the rsb keep data structure with a refcount of 1 but no lkb was associated with it, which is itself an invalid behaviour. A side effect of that was a condition in which the dlm was sending remove messages in a looping behaviour. With this patch that has not been reproduced. Cc: stable@vger.kernel.org Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Greg Kroah-Hartman --- fs/dlm/lock.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) --- a/fs/dlm/lock.c +++ b/fs/dlm/lock.c @@ -1559,6 +1559,7 @@ static int _remove_from_waiters(struct d lkb->lkb_wait_type = 0; lkb->lkb_flags &= ~DLM_IFL_OVERLAP_CANCEL; lkb->lkb_wait_count--; + unhold_lkb(lkb); goto out_del; } @@ -1585,6 +1586,7 @@ static int _remove_from_waiters(struct d log_error(ls, "remwait error %x reply %d wait_type %d overlap", lkb->lkb_id, mstype, lkb->lkb_wait_type); lkb->lkb_wait_count--; + unhold_lkb(lkb); lkb->lkb_wait_type = 0; } @@ -5331,11 +5333,16 @@ int dlm_recover_waiters_post(struct dlm_ lkb->lkb_flags &= ~DLM_IFL_OVERLAP_UNLOCK; lkb->lkb_flags &= ~DLM_IFL_OVERLAP_CANCEL; lkb->lkb_wait_type = 0; - lkb->lkb_wait_count = 0; + /* drop all wait_count references we still + * hold a reference for this iteration. + */ + while (lkb->lkb_wait_count) { + lkb->lkb_wait_count--; + unhold_lkb(lkb); + } mutex_lock(&ls->ls_waiters_mutex); list_del_init(&lkb->lkb_wait_reply); mutex_unlock(&ls->ls_waiters_mutex); - unhold_lkb(lkb); /* for waiters list */ if (oc || ou) { /* do an unlock or cancel instead of resending */