From: Max Reitz <mreitz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>, qemu-block@nongnu.org
Cc: dplotnikov@virtuozzo.com, vsementsov@virtuozzo.com,
den@virtuozzo.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 3/4] mirror: Keep target drained until graph changes are done
Date: Fri, 26 Jul 2019 11:52:53 +0200 [thread overview]
Message-ID: <d6466e56-b57b-7cf7-1a39-8cd38db14ede@redhat.com> (raw)
In-Reply-To: <20190725162704.12622-4-kwolf@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 3966 bytes --]
On 25.07.19 18:27, Kevin Wolf wrote:
> Calling bdrv_drained_end() for target_bs can restarts requests too
> early, so that they would execute on mirror_top_bs, which however has
> already dropped all permissions.
>
> Keep the target node drained until all graph changes have completed.
>
> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> ---
> block/mirror.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/block/mirror.c b/block/mirror.c
> index 8cb75fb409..7483051f8d 100644
> --- a/block/mirror.c
> +++ b/block/mirror.c
> @@ -644,6 +644,11 @@ static int mirror_exit_common(Job *job)
> bdrv_ref(mirror_top_bs);
> bdrv_ref(target_bs);
>
> + /* The mirror job has no requests in flight any more, but we need to
> + * drain potential other users of the BDS before changing the graph. */
> + assert(s->in_drain);
> + bdrv_drained_begin(target_bs);
> +
In contrast to what Eric said, I think it is a problem that this is just
code motion.
The comment doesn’t tell the reason why the target needs to be drained
here. Other users of the BDS have their own BdrvChild and thus their
own permissions, their requests do not go through mirror.
So in addition to why the target needs to be drained around
bdrv_replace_node(), the comment should tell why we need to drain it
here, like the commit message does.
Now, the thing is, I don’t quite understand the connection between the
target and mirror_top_bs that the commit message wants to establish.
I see the following problem:
(1) We drain src (at the end of mirror_run()).
(2) This implicitly drains mirror_top_bs.
(3) We drain target.
(4) bdrv_replace_node() replaces src by target, thus replacing the drain
on mirror_top_bs from src by the one from target.
(5) We undrain target, thus also undraining mirror_top_bs.
(6) After all is done, we undrain src, which has no effect on
mirror_top_bs, because they haven’t been connected since (4).
I suppose (5) is the problem. This patch moves it down to (6), so
mirror_top_bs is drained as long as src is drained.
(If to_replace is not src, then src will stay attached, which keeps
mirror_top_bs drained, too.)
This makes it seem to me like the actually important thing is to drain
mirror_top_bs, not target. If so, it would seem more obvious to me to
just add a drain on mirror_top_bs than to move the existing target drain.
> /* Remove target parent that still uses BLK_PERM_WRITE/RESIZE before
> * inserting target_bs at s->to_replace, where we might not be able to get
> * these permissions.
> @@ -684,12 +689,7 @@ static int mirror_exit_common(Job *job)
> bdrv_reopen_set_read_only(target_bs, ro, NULL);
> }
>
> - /* The mirror job has no requests in flight any more, but we need to
> - * drain potential other users of the BDS before changing the graph. */
> - assert(s->in_drain);
> - bdrv_drained_begin(target_bs);
By the way, don’t we need to drain to_replace also? In case it isn’t src?
Max
> bdrv_replace_node(to_replace, target_bs, &local_err);
> - bdrv_drained_end(target_bs);
> if (local_err) {
> error_report_err(local_err);
> ret = -EPERM;
> @@ -704,7 +704,6 @@ static int mirror_exit_common(Job *job)
> aio_context_release(replace_aio_context);
> }
> g_free(s->replaces);
> - bdrv_unref(target_bs);
>
> /*
> * Remove the mirror filter driver from the graph. Before this, get rid of
> @@ -724,9 +723,12 @@ static int mirror_exit_common(Job *job)
> bs_opaque->job = NULL;
>
> bdrv_drained_end(src);
> + bdrv_drained_end(target_bs);
> +
> s->in_drain = false;
> bdrv_unref(mirror_top_bs);
> bdrv_unref(src);
> + bdrv_unref(target_bs);
>
> return ret;
> }
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-07-26 9:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-25 16:27 [Qemu-devel] [PATCH 0/4] block-backend: Queue requests while drained Kevin Wolf
2019-07-25 16:27 ` [Qemu-devel] [PATCH 1/4] block: Remove blk_pread_unthrottled() Kevin Wolf
2019-07-26 9:18 ` Max Reitz
2019-07-25 16:27 ` [Qemu-devel] [PATCH 2/4] block: Reduce (un)drains when replacing a child Kevin Wolf
2019-07-25 16:27 ` [Qemu-devel] [PATCH 3/4] mirror: Keep target drained until graph changes are done Kevin Wolf
2019-07-25 17:03 ` Eric Blake
2019-07-26 9:52 ` Max Reitz [this message]
2019-07-26 11:36 ` Kevin Wolf
2019-07-26 12:30 ` Max Reitz
2019-07-25 16:27 ` [Qemu-devel] [PATCH 4/4] block-backend: Queue requests while drained Kevin Wolf
2019-07-25 17:06 ` Eric Blake
2019-07-26 10:50 ` Max Reitz
2019-07-26 11:49 ` Kevin Wolf
2019-07-26 12:34 ` Max Reitz
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=d6466e56-b57b-7cf7-1a39-8cd38db14ede@redhat.com \
--to=mreitz@redhat.com \
--cc=den@virtuozzo.com \
--cc=dplotnikov@virtuozzo.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.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;
as well as URLs for NNTP newsgroup(s).