All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: John Snow <jsnow@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>
Cc: Fam Zheng <fam@euphon.net>,
	Peter Maydell <peter.maydell@linaro.org>,
	aihua liang <aliang@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2] migration/dirty-bitmaps: change bitmap enumeration method
Date: Thu, 16 May 2019 10:12:30 +0000	[thread overview]
Message-ID: <72986b5d-0772-abfb-2c99-97470e8fd3da@virtuozzo.com> (raw)
In-Reply-To: <20190514201926.10407-1-jsnow@redhat.com>

14.05.2019 23:19, John Snow wrote:
> Shift from looking at every root BDS to *every* BDS. This will migrate
> bitmaps that are attached to blockdev created nodes instead of just ones
> attached to emulated storage devices.
> 
> Note that this will not migrate anonymous or internal-use bitmaps, as
> those are defined as having no name.
> 
> This will also fix the Coverity issues Peter Maydell has been asking
> about for the past several releases, as well as fixing a real bug.
> 
> Reported-by: Peter Maydell <peter.maydell@linaro.org>
> Reported-by: Coverity 😅
> Reported-by: aihua liang <aliang@redhat.com>
> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1652490
> Fixes: Coverity CID 1390625
> CC: Stefan Hajnoczi <stefanha@redhat.com>
> Signed-off-by: John Snow <jsnow@redhat.com>
> ---
>   migration/block-dirty-bitmap.c | 14 ++++----------
>   1 file changed, 4 insertions(+), 10 deletions(-)
> 
> diff --git a/migration/block-dirty-bitmap.c b/migration/block-dirty-bitmap.c
> index d1bb863cb6..4a896a09eb 100644
> --- a/migration/block-dirty-bitmap.c
> +++ b/migration/block-dirty-bitmap.c
> @@ -273,7 +273,6 @@ static int init_dirty_bitmap_migration(void)
>       BlockDriverState *bs;
>       BdrvDirtyBitmap *bitmap;
>       DirtyBitmapMigBitmapState *dbms;
> -    BdrvNextIterator it;
>       Error *local_err = NULL;
>   
>       dirty_bitmap_mig_state.bulk_completed = false;
> @@ -281,13 +280,8 @@ static int init_dirty_bitmap_migration(void)
>       dirty_bitmap_mig_state.prev_bitmap = NULL;
>       dirty_bitmap_mig_state.no_bitmaps = false;
>   
> -    for (bs = bdrv_first(&it); bs; bs = bdrv_next(&it)) {
> -        const char *drive_name = bdrv_get_device_or_node_name(bs);
> -
> -        /* skip automatically inserted nodes */
> -        while (bs && bs->drv && bs->implicit) {
> -            bs = backing_bs(bs);
> -        }

hm, so, after the patch, for implicitly-filtered nodes we'll have node_name instead of device name..

But, on the other, hand, if we have implicitly-filtered node on target, we were doing wrong thing anyway,
as dirty_bitmap_load_header don't skip implicit nodes.

> +    for (bs = bdrv_next_all_states(NULL); bs; bs = bdrv_next_all_states(bs)) {

As I understand, difference with bdrv_next_node is that we don't skip unnamed nodes [...]

> +        const char *name = bdrv_get_device_or_node_name(bs);
>   
>           for (bitmap = bdrv_dirty_bitmap_next(bs, NULL); bitmap;
>                bitmap = bdrv_dirty_bitmap_next(bs, bitmap))
> @@ -296,7 +290,7 @@ static int init_dirty_bitmap_migration(void)
>                   continue;
>               }
>   
> -            if (drive_name == NULL) {
> +            if (!name || strcmp(name, "") == 0) {

[...] to do this (may be paranoiac, but why not?) check

>                   error_report("Found bitmap '%s' in unnamed node %p. It can't "
>                                "be migrated", bdrv_dirty_bitmap_name(bitmap), bs);
>                   goto fail;
> @@ -313,7 +307,7 @@ static int init_dirty_bitmap_migration(void)
>   
>               dbms = g_new0(DirtyBitmapMigBitmapState, 1);
>               dbms->bs = bs;
> -            dbms->node_name = drive_name;
> +            dbms->node_name = name;
>               dbms->bitmap = bitmap;
>               dbms->total_sectors = bdrv_nb_sectors(bs);
>               dbms->sectors_per_chunk = CHUNK_SIZE * 8 *
> 

There is still some mess about device name vs node name, and I don't know, could we somehow
solve it, but patch looks OK for me anyway:

Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>

-- 
Best regards,
Vladimir

  reply	other threads:[~2019-05-16 10:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-14 20:19 [Qemu-devel] [PATCH v2] migration/dirty-bitmaps: change bitmap enumeration method John Snow
2019-05-16 10:12 ` Vladimir Sementsov-Ogievskiy [this message]
2019-05-16 19:03   ` John Snow
2019-05-17 10:22     ` Vladimir Sementsov-Ogievskiy
2019-05-20  9:27       ` [Qemu-devel] [Qemu-block] " Kevin Wolf
2019-05-20 10:37         ` Vladimir Sementsov-Ogievskiy
2019-05-20 16:43           ` John Snow
2019-12-06 22:31 ` Vladimir Sementsov-Ogievskiy
2019-12-09 15:22   ` John Snow
2019-12-09 15:26     ` John Snow
2019-12-09 15:45       ` John Snow
2019-12-09 17:17       ` Vladimir Sementsov-Ogievskiy
2019-12-09 18:15         ` John Snow

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=72986b5d-0772-abfb-2c99-97470e8fd3da@virtuozzo.com \
    --to=vsementsov@virtuozzo.com \
    --cc=aliang@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=fam@euphon.net \
    --cc=jsnow@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=stefanha@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.