Received-SPF: pass (google.com: domain of linux-kernel+bounces-36368-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240120103734.4155446-1-yukuai1@huaweicloud.com> <20240120103734.4155446-4-yukuai1@huaweicloud.com>
In-Reply-To: <20240120103734.4155446-4-yukuai1@huaweicloud.com>
From: Xiao Ni <xni@redhat.com>
Date: Wed, 24 Jan 2024 10:58:21 +0800
Message-ID: <CALTww28NL+yBT8bcL2=ATJr79eL45=TF-EXHUD8NsfCXXTG3Qw@mail.gmail.com>
Subject: Re: [PATCH 3/5] md: make sure md_do_sync() will set MD_RECOVERY_DONE
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: mpatocka@redhat.com, dm-devel@lists.linux.dev, msnitzer@redhat.com, 
	heinzm@redhat.com, song@kernel.org, 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

Hi all

MD_RECOVERY_WAIT was introduced in d5d885fd5. From this patch,
MD_RECOVERY_WAIT only has one usage during creating raid device.
resync job needs to wait until pers->start finishes(The only place
which is checked). If we remove it from md_do_sync, will it break the
logic? Or we don't need this flag anymore? If so can we remove this
flag?

dm-raid uses this bit in patch 644e2537f (dm raid: fix stripe adding
reshape deadlock). It's the reason why md_do_sync can't set
MD_RECOVERY_DONE. Now we stop sync thread asynchronously, can we
revert this patch?

Best Regards
Xiao

On Sat, Jan 20, 2024 at 6:41=E2=80=AFPM Yu Kuai <yukuai1@huaweicloud.com> w=
rote:
>
> From: Yu Kuai <yukuai3@huawei.com>
>
> stop_sync_thread() will interrupt md_do_sync(), and md_do_sync() must
> set MD_RECOVERY_DONE, so that follow up md_check_recovery() will
> unregister sync_thread, clear MD_RECOVERY_RUNNING and wake up
> stop_sync_thread().
>
> Before this patch, if MD_RECOVERY_WAIT is set or the array is read-only,
> md_do_sync() will return without setting MD_RECOVERY_DONE, hence use
> stop_sync_thread() directly will hang because md_check_recovery() can't
> clear MD_RECOVERY_RUNNING, which is possible for dm-raid.
>
> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> ---
>  drivers/md/md.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 6906d023f1d6..ba45c7be3dbe 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -8788,12 +8788,13 @@ void md_do_sync(struct md_thread *thread)
>         int ret;
>
>         /* just incase thread restarts... */
> -       if (test_bit(MD_RECOVERY_DONE, &mddev->recovery) ||
> -           test_bit(MD_RECOVERY_WAIT, &mddev->recovery))
> +       if (test_bit(MD_RECOVERY_DONE, &mddev->recovery))
>                 return;
> -       if (!md_is_rdwr(mddev)) {/* never try to sync a read-only array *=
/
> +
> +       if (test_bit(MD_RECOVERY_WAIT, &mddev->recovery) ||
> +           !md_is_rdwr(mddev)) {/* never try to sync a read-only array *=
/
>                 set_bit(MD_RECOVERY_INTR, &mddev->recovery);
> -               return;
> +               goto out;
>         }
>
>         if (mddev_is_clustered(mddev)) {
> @@ -9171,6 +9172,7 @@ void md_do_sync(struct md_thread *thread)
>                                                 mddev->array_sectors);
>         }
>
> +out:
>         spin_lock(&mddev->lock);
>         if (!test_bit(MD_RECOVERY_INTR, &mddev->recovery)) {
>                 /* We completed so min/max setting can be forgotten if us=
ed. */
> --
> 2.39.2
>
>