From: John Snow <jsnow@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.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: [PATCH v2] migration/dirty-bitmaps: change bitmap enumeration method
Date: Mon, 9 Dec 2019 10:22:49 -0500 [thread overview]
Message-ID: <d164961f-4da7-3678-2f56-5486cee3d07d@redhat.com> (raw)
In-Reply-To: <aab4e1c7-37eb-5b3e-26d2-fca33ba87662@virtuozzo.com>
On 12/6/19 5:31 PM, Vladimir Sementsov-Ogievskiy wrote:
> 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 😅
>
> What was the coverity number (I don't believe that it was smile:)?
>
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Reported-by: Coverity 😅
Reported-by: aihua liang <aliang@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Message-id: 20190514201926.10407-1-jsnow@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>
> Do someone know, that this patch fixes very-very-very terrible bug?
>
> Before this patch, here were bdrv_next-based loop, with exists from it,
> but not using bdrv_next_cleanup(). This leads to leaked (incremented) refcnt of
> bds on any failure during this loop!
>
> Now we faced this bug, in Rhel-based Qemu, so I strongly recommend to fix it in Rhel.
OK, this was fixed for 4.1, and was introduced in b35ebdf076d for
2.12.0, so all versions between have the problem.
>
>> 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);
>> - }
>> + for (bs = bdrv_next_all_states(NULL); bs; bs = bdrv_next_all_states(bs)) {
>> + 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) {
>> 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 *
>>
>
>
next prev parent reply other threads:[~2019-12-09 15:25 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
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 [this message]
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=d164961f-4da7-3678-2f56-5486cee3d07d@redhat.com \
--to=jsnow@redhat.com \
--cc=aliang@redhat.com \
--cc=dgilbert@redhat.com \
--cc=fam@euphon.net \
--cc=peter.maydell@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=stefanha@redhat.com \
--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).