Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2204753iof; Tue, 7 Jun 2022 23:08:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy8VcBkrW3CGWdc17kss2JXKizQ4pF3JglmHEdIihmMAw41qYY7r1QCXRa+/p+1NAM3RCZI X-Received: by 2002:a17:902:c40a:b0:163:d38e:3049 with SMTP id k10-20020a170902c40a00b00163d38e3049mr32385660plk.87.1654668531758; Tue, 07 Jun 2022 23:08:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654668531; cv=none; d=google.com; s=arc-20160816; b=TAhUtIDwE2EdCKbOvGJpGG+9Qx+GmP/4/KpIlAcfsNfMSg4C4HOe7HIWnfvujbV11q 544KWzZmcDKWGm/FHkG+zuL2HUa+IfZm77ImfIP4R0KlCR4EXshzIxF6xRC9G1WgNqlF nBm7NWbTRdnI/wL7g/NZlYJBkctlRRRlfPAn4kGXPkXi1XTwchW/SttqqHPWyhTGd/mf 0XqirhbqmWIk7FRwN3328Pd9LmkpGBa+rFE61oX76BX8Ro+7ooHYmA6LIEhPGfDYQ33A UfnEr+v7dmFq9mKiQH155Xlm6PiEQuL4WDM6pKFcSZom7Q+zHPhLmHZ0qvTGwySpoDHC aLXQ== 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=DX3KPxlw/UXwMxyRD5EdvIkdKe/XqXmyhlGz8c3D8Pc=; b=LWdwi55GPEXIaLyKPyVGvzlrtEWxzAqLS7Etkj4P3DJQeBXmFkl3bbmdBdEIlPd89A AdDrvDbE9TOKQ+hWBujbnHxShPSyO5sX/lOav00SvZ2WY2K+P7IjMXWEiVh6XuTi6Tor xA0hTzNQoe1HK3WmOWSNlhSRT51Cnrv2e4TdmEXUQDoU50QCQ4pURUOKbLA5AowGqzmy Rqnh1ESi6r5e0eYHOZ+NYPJOyf/ZQ6+pQ6mzcjGfwJ0KpRTltuAYR7CD7tCXHNxe7ldB MnGq4BgwhLFW2suMrKaBxU9xElLj5GjAWS1ZFLmY0Cozf1C4U7JWKKO78W5e6uPY41hI sAvA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=RLGqbIlE; 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 f190-20020a636ac7000000b003fcb19cf926si27967908pgc.48.2022.06.07.23.08.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jun 2022 23:08:51 -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=RLGqbIlE; 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 93D88E2071; Tue, 7 Jun 2022 22:31:46 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243307AbiFHBbz (ORCPT + 99 others); Tue, 7 Jun 2022 21:31:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49788 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358031AbiFGWVv (ORCPT ); Tue, 7 Jun 2022 18:21:51 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 991C326D275; Tue, 7 Jun 2022 12:22:31 -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 sin.source.kernel.org (Postfix) with ESMTPS id 1CB89CE2476; Tue, 7 Jun 2022 19:22:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E233EC385A2; Tue, 7 Jun 2022 19:22:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654629747; bh=DerCkNsI2Cf3QemMT/beBdirNFSwUzXe5oOGb6F9b4A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RLGqbIlEpTRqjEEQxW7IRL55tmHEpAT/+aB7/22wQCdVwjIM9VlhhgOPJAJCPYTEN Jd+5gLjqcO7PsbMDFRNqgEjB06meZrRnd4vD2pB8DcjIeNjYiAcc5F7ZMsSR1jrocp t+JRWDyNAB3+D0y3ZuqK1g1+8h85Dof7T4TCAzPc= 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 765/879] dlm: fix wake_up() calls for pending remove Date: Tue, 7 Jun 2022 19:04:43 +0200 Message-Id: <20220607165025.068730715@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 f6f7418357457ed58cbb020fc97e74d4e0e7b47f upstream. This patch move the wake_up() call at the point when a remove message completed. Before it was only when a remove message was going to be sent. The possible waiter in wait_pending_remove() waits until a remove is done if the resource name matches with the per ls variable ls->ls_remove_name. If this is the case we must wait until a pending remove is done which is indicated if DLM_WAIT_PENDING_COND() returns false which will always be the case when ls_remove_len and ls_remove_name are unset to indicate that a remove is not going on anymore. Fixes: 21d9ac1a5376 ("fs: dlm: use event based wait for pending remove") 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 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/dlm/lock.c +++ b/fs/dlm/lock.c @@ -1795,7 +1795,6 @@ static void shrink_bucket(struct dlm_ls memcpy(ls->ls_remove_name, name, DLM_RESNAME_MAXLEN); spin_unlock(&ls->ls_remove_spin); spin_unlock(&ls->ls_rsbtbl[b].lock); - wake_up(&ls->ls_remove_wait); send_remove(r); @@ -1804,6 +1803,7 @@ static void shrink_bucket(struct dlm_ls ls->ls_remove_len = 0; memset(ls->ls_remove_name, 0, DLM_RESNAME_MAXLEN); spin_unlock(&ls->ls_remove_spin); + wake_up(&ls->ls_remove_wait); dlm_free_rsb(r); } @@ -4079,7 +4079,6 @@ static void send_repeat_remove(struct dl memcpy(ls->ls_remove_name, name, DLM_RESNAME_MAXLEN); spin_unlock(&ls->ls_remove_spin); spin_unlock(&ls->ls_rsbtbl[b].lock); - wake_up(&ls->ls_remove_wait); rv = _create_message(ls, sizeof(struct dlm_message) + len, dir_nodeid, DLM_MSG_REMOVE, &ms, &mh); @@ -4095,6 +4094,7 @@ static void send_repeat_remove(struct dl ls->ls_remove_len = 0; memset(ls->ls_remove_name, 0, DLM_RESNAME_MAXLEN); spin_unlock(&ls->ls_remove_spin); + wake_up(&ls->ls_remove_wait); } static int receive_request(struct dlm_ls *ls, struct dlm_message *ms)