Received: by 2002:a05:7412:b10a:b0:f3:1519:9f41 with SMTP id az10csp1357207rdb; Fri, 1 Dec 2023 14:11:08 -0800 (PST) X-Google-Smtp-Source: AGHT+IHIiRHo01nH3IgxdwHawr1fIEz9Y0lr66mPc+I3p8WGqFaAcWAC/vnysStWFIF8bH1ESJgM X-Received: by 2002:a05:6a20:2214:b0:181:15:5755 with SMTP id u20-20020a056a20221400b0018100155755mr216911pzb.56.1701468667633; Fri, 01 Dec 2023 14:11:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701468667; cv=none; d=google.com; s=arc-20160816; b=zMiHA3XRIfwEImytxDZ0fUe2Lj70XmJEOxgHwwtTDC7V3IqCtWGliNHKumJJhxzybh QoNuWgGTHHpgT5f3BkUVP0DzexaO90iAbFiH38i/y2Ru4Zt0u1dp/TVJRJPRR5CPYZcQ 7n/awd9IQxcBmmf5txs8YxADwOrZdFlzaMqhf+YF/Qc3M7Tef+XP+iYxi15m96ec8KuG QlOWy7qXeaE76z50MyRchY5rBcAtEI3jXAaCSNF84/xqDUoXW93zidnHhnCy336j3sHy 5xFbR/ilOK290FLu04WST8JbYMQULkp1eNH+CByXPD9H/h/eoXQGG5vQgIgj4rRU4NIo EL3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=U6f3PJOo0iLUTgFcIjAMA2U6xS+9Z5I40qVOCj4ktek=; fh=15yukcBU1xa/TgDqJJ3LEr6UktwxA/S59ko/85R7lk8=; b=oIU6yt8aqJCCN7NSIW0Xc8i0V+NzRv1vec9lI8V1EMCBh/jstSTEcpeb6/DWYiB7QE 2+WE6BcdeTyY0DnXHQAxacE36p8Qgx99mag5k7beK8nIOBiwC9ewvlDAX5LDdG4qxbez jZVUWBje0iIDGGSm/2tXT2PnTfh2VfU/CWIOPu6faCAY63kUqNuafkdAE45mjKyURvG7 mv45OMUT1523QK1ltV8b0fQ3ISTOQjUwWMBw+LldvfGUm8E0AP0R36YzS+34Pu3oxHq2 6rggQExik1ND/CvX13ynmi8JTMf4OHkMH/VXSM7WcTB3cWdBIN0WoZ4b9POnPyMGj0Dt x7yA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qfXuNNAC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from pete.vger.email (pete.vger.email. [2620:137:e000::3:6]) by mx.google.com with ESMTPS id h11-20020a056a00230b00b006cbb7fdff10si4078176pfh.194.2023.12.01.14.11.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Dec 2023 14:11:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qfXuNNAC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id D93238082712; Fri, 1 Dec 2023 14:10:34 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231145AbjLAWIU (ORCPT + 99 others); Fri, 1 Dec 2023 17:08:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34584 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229456AbjLAWIU (ORCPT ); Fri, 1 Dec 2023 17:08:20 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6F5B210D for ; Fri, 1 Dec 2023 14:08:26 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D893BC433C7; Fri, 1 Dec 2023 22:08:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701468505; bh=J5w34K9IrU/nR2a8B14bwImOYjReMdTVS9JU/XNvSsM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=qfXuNNACF7hA0zP4Ro4689MIjK0/2F1aOBAT/G0zwtzTIjnYMcoxCWS6RjHDeVk/x xZu0qNhJlmR9figpgQo5rTN1w+7GOjYTz3FoZPYMwrDQG+zQ7rsG8dnfrO81tO0o1P aoEzy25IPws+/yPeAB6HkdxNzdmNHXqc6FPGU/n9qxk3v3Gyn1ElCs3W+hqdUN95pW emw6LaECUJNUM3oyvzY11C98NWqYRF4LmMa5MSBe9XeRAGE2g+RBlEEpf8i4GE/N+m V8RPAxz998LeavKHGQdSdaO8mIwp0G26dy2y5wIkCw8CjHCNGcilVyTT4dhNhFPoEN naaRKXvkSlueA== Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-2c9ee6fed3eso1451721fa.0; Fri, 01 Dec 2023 14:08:25 -0800 (PST) X-Gm-Message-State: AOJu0YwfMraCFkEz1mh/xCiWER8971UVzPUVe/r7Wm3VuuKUAVFv6Clo t258WL5//KVk+9Dsav8GXKjJSwsErdhI0N+qVPk= X-Received: by 2002:a2e:99c5:0:b0:2c9:e9eb:8ccb with SMTP id l5-20020a2e99c5000000b002c9e9eb8ccbmr345272ljj.69.1701468504052; Fri, 01 Dec 2023 14:08:24 -0800 (PST) MIME-Version: 1.0 References: <20231129043127.2245901-1-yukuai1@huaweicloud.com> <20231129043127.2245901-4-yukuai1@huaweicloud.com> In-Reply-To: <20231129043127.2245901-4-yukuai1@huaweicloud.com> From: Song Liu Date: Fri, 1 Dec 2023 14:08:11 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 3/3] md: fix stopping sync thread To: Yu Kuai Cc: xni@redhat.com, yukuai3@huawei.com, linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org, yi.zhang@huawei.com, yangerkun@huawei.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,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 pete.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Fri, 01 Dec 2023 14:10:35 -0800 (PST) On Tue, Nov 28, 2023 at 8:32=E2=80=AFPM Yu Kuai w= rote: > > From: Yu Kuai > > Currently sync thread is stopped from multiple contex: > - idle_sync_thread > - frozen_sync_thread > - __md_stop_writes > - md_set_readonly > - do_md_stop > > And there are some problems: > 1) sync_work is flushed while reconfig_mutex is grabbed, this can > deadlock because the work function will grab reconfig_mutex as well. > 2) md_reap_sync_thread() can't be called directly while md_do_sync() is > not finished yet, for example, commit 130443d60b1b ("md: refactor > idle/frozen_sync_thread() to fix deadlock"). > 3) If MD_RECOVERY_RUNNING is not set, there is no need to stop > sync_thread at all because sync_thread must not be registered. > > Factor out a helper prepare_to_stop_sync_thread(), so that above contex > will behave the same. Fix 1) by flushing sync_work after reconfig_mutex > is released, before waiting for sync_thread to be done; Fix 2) bt > letting daemon thread to unregister sync_thread; Fix 3) by always > checking MD_RECOVERY_RUNNING first. > > Fixes: db5e653d7c9f ("md: delay choosing sync action to md_start_sync()") > Acked-by: Xiao Ni > > Signed-off-by: Yu Kuai > --- > drivers/md/md.c | 96 +++++++++++++++++++++++-------------------------- > 1 file changed, 45 insertions(+), 51 deletions(-) > > diff --git a/drivers/md/md.c b/drivers/md/md.c > index 2d8e45a1af23..05902e36db66 100644 > --- a/drivers/md/md.c > +++ b/drivers/md/md.c > @@ -4840,26 +4840,9 @@ action_show(struct mddev *mddev, char *page) > return sprintf(page, "%s\n", type); > } > > -static void stop_sync_thread(struct mddev *mddev) > +static void prepare_to_stop_sync_thread(struct mddev *mddev) > + __releases(&mddev->reconfig_mutex) > { > - if (!test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) > - return; > - > - if (mddev_lock(mddev)) > - return; > - > - /* > - * Check again in case MD_RECOVERY_RUNNING is cleared before lock= is > - * held. > - */ > - if (!test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) { > - mddev_unlock(mddev); > - return; > - } > - > - if (work_pending(&mddev->sync_work)) > - flush_workqueue(md_misc_wq); > - > set_bit(MD_RECOVERY_INTR, &mddev->recovery); > /* > * Thread might be blocked waiting for metadata update which will= now > @@ -4868,6 +4851,8 @@ static void stop_sync_thread(struct mddev *mddev) > md_wakeup_thread_directly(mddev->sync_thread); > > mddev_unlock(mddev); > + if (work_pending(&mddev->sync_work)) > + flush_work(&mddev->sync_work); > } > > static void idle_sync_thread(struct mddev *mddev) > @@ -4876,10 +4861,20 @@ static void idle_sync_thread(struct mddev *mddev) > > mutex_lock(&mddev->sync_mutex); > clear_bit(MD_RECOVERY_FROZEN, &mddev->recovery); > - stop_sync_thread(mddev); > > - wait_event(resync_wait, sync_seq !=3D atomic_read(&mddev->sync_se= q) || > + if (mddev_lock(mddev)) { > + mutex_unlock(&mddev->sync_mutex); > + return; > + } > + > + if (test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) { > + prepare_to_stop_sync_thread(mddev); > + wait_event(resync_wait, > + sync_seq !=3D atomic_read(&mddev->sync_seq) || > !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))= ; > + } else { > + mddev_unlock(mddev); > + } We have a few patterns like this: if (test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) { prepare_to_stop_sync_thread(mddev); wait_event(resync_wait, sync_seq !=3D atomic_read(&mddev->sync_seq) || !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)); } else { mddev_unlock(mddev); } This is pretty confusing. Maybe try something like (untested) static void stop_sync_thread(struct mddev *mddev, bool do_unlock, bool check_sync_seq) { if (test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) { if (do_unlock) mddev_unlock(mddev); return; } set_bit(MD_RECOVERY_INTR, &mddev->recovery); /* * Thread might be blocked waiting for metadata update which will n= ow * never happen */ md_wakeup_thread_directly(mddev->sync_thread); mddev_unlock(mddev); if (work_pending(&mddev->sync_work)) flush_work(&mddev->sync_work); wait_event(resync_wait, !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery) || (check_sync_seq && sync_seq !=3D atomic_read(&mddev->sync_seq))); if (!do_unlock) mddev_lock_nointr(mddev); } Thanks, Song