From: Mikulas Patocka <mpatocka@redhat.com>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: heinzm@redhat.com, xni@redhat.com, agk@redhat.com,
snitzer@kernel.org, dm-devel@lists.linux.dev, song@kernel.org,
yukuai3@huawei.com, jbrassow@f14.redhat.com, neilb@suse.de,
shli@fb.com, akpm@osdl.org, linux-kernel@vger.kernel.org,
linux-raid@vger.kernel.org, yi.zhang@huawei.com,
yangerkun@huawei.com
Subject: Re: [PATCH RFC v4 13/14] dm: wait for IO completion before removing dm device
Date: Tue, 30 Jan 2024 12:46:08 +0100 (CET) [thread overview]
Message-ID: <fa4cd2f8-d0e8-5b6d-2ac6-1c5f1710a5ee@redhat.com> (raw)
In-Reply-To: <20240130021843.3608859-14-yukuai1@huaweicloud.com>
On Tue, 30 Jan 2024, Yu Kuai wrote:
> From: Yu Kuai <yukuai3@huawei.com>
>
> __dm_destroy() guarantee that device openers is zero, and then
> only call 'presuspend' and 'postsuspend' for the target. For
> request-based dm, 'md->holders' will be grabbed for each rq and
> __dm_destroy() will wait for 'md->holders' to be zero. However, for
> bio-based device, __dm_destroy() doesn't wait for all bios to be done.
>
> Fix this problem by calling dm_wait_for_completion() to wail for all
> inflight IO to be done, like what dm_suspend() does.
If the number of openers is zero, it is guaranteed that there are no bios
in flight. Therefore, we don't have to wait for them.
If there are bios in flight, it is a bug in the code that issues the bios.
You can put WARN_ON(dm_in_flight_bios(md)) there.
Mikulas
> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> ---
> drivers/md/dm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/md/dm.c b/drivers/md/dm.c
> index 8dcabf84d866..2c0eae67d0f1 100644
> --- a/drivers/md/dm.c
> +++ b/drivers/md/dm.c
> @@ -58,6 +58,7 @@ static DEFINE_IDR(_minor_idr);
> static DEFINE_SPINLOCK(_minor_lock);
>
> static void do_deferred_remove(struct work_struct *w);
> +static int dm_wait_for_completion(struct mapped_device *md, unsigned int task_state);
>
> static DECLARE_WORK(deferred_remove_work, do_deferred_remove);
>
> @@ -2495,6 +2496,8 @@ static void __dm_destroy(struct mapped_device *md, bool wait)
> if (!dm_suspended_md(md)) {
> dm_table_presuspend_targets(map);
> set_bit(DMF_SUSPENDED, &md->flags);
> + if (wait)
> + dm_wait_for_completion(md, TASK_UNINTERRUPTIBLE);
> set_bit(DMF_POST_SUSPENDING, &md->flags);
> dm_table_postsuspend_targets(map);
> }
> --
> 2.39.2
>
next prev parent reply other threads:[~2024-01-30 11:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-30 2:18 [PATCH v4 00/14] dm-raid: fix v6.7 regressions Yu Kuai
2024-01-30 2:18 ` [PATCH v4 01/14] md: don't ignore suspended array in md_check_recovery() Yu Kuai
2024-01-30 2:18 ` [PATCH v4 02/14] md: don't ignore read-only " Yu Kuai
2024-01-30 2:18 ` [PATCH v4 03/14] md: make sure md_do_sync() will set MD_RECOVERY_DONE Yu Kuai
2024-01-30 2:18 ` [PATCH v4 04/14] md: don't register sync_thread for reshape directly Yu Kuai
2024-01-30 2:18 ` [PATCH v4 05/14] md: export helpers to stop sync_thread Yu Kuai
2024-01-30 2:18 ` [PATCH v4 06/14] dm-raid: really frozen sync_thread during suspend Yu Kuai
2024-01-30 2:18 ` [PATCH v4 07/14] md/dm-raid: don't call md_reap_sync_thread() directly Yu Kuai
2024-01-30 2:18 ` [PATCH v4 08/14] dm-raid: add a new helper prepare_suspend() in md_personality Yu Kuai
2024-01-30 2:18 ` [PATCH v4 09/14] md: export helper md_is_rdwr() Yu Kuai
2024-01-30 2:18 ` [PATCH v4 10/14] md: don't suspend the array for interrupted reshape Yu Kuai
2024-01-30 2:18 ` [PATCH v4 11/14] md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape Yu Kuai
2024-01-30 2:18 ` [PATCH v4 12/14] dm-raid: fix lockdep waring in "pers->hot_add_disk" Yu Kuai
2024-01-30 2:18 ` [PATCH RFC v4 13/14] dm: wait for IO completion before removing dm device Yu Kuai
2024-01-30 11:46 ` Mikulas Patocka [this message]
2024-01-30 13:05 ` Yu Kuai
2024-01-31 1:35 ` Yu Kuai
2024-01-30 2:18 ` [PATCH v4 RFC 14/14] dm-raid: remove mddev_suspend/resume() Yu Kuai
2024-01-31 2:51 ` Yu Kuai
2024-01-30 9:08 ` [PATCH v4 00/14] dm-raid: fix v6.7 regressions Song Liu
2024-01-31 0:29 ` Xiao Ni
2024-01-31 1:25 ` Yu Kuai
2024-01-31 1:28 ` Xiao Ni
2024-01-31 2:52 ` Yu Kuai
2024-01-31 7:06 ` Yu Kuai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fa4cd2f8-d0e8-5b6d-2ac6-1c5f1710a5ee@redhat.com \
--to=mpatocka@redhat.com \
--cc=agk@redhat.com \
--cc=akpm@osdl.org \
--cc=dm-devel@lists.linux.dev \
--cc=heinzm@redhat.com \
--cc=jbrassow@f14.redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
--cc=shli@fb.com \
--cc=snitzer@kernel.org \
--cc=song@kernel.org \
--cc=xni@redhat.com \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai1@huaweicloud.com \
--cc=yukuai3@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®