[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 15/21] migration/block-dirty-bitmap: relax error handling

From: Eric Blake
Subject: Re: [PATCH v3 15/21] migration/block-dirty-bitmap: relax error handling in incoming part
Date: Fri, 24 Jul 2020 12:35:49 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 7/24/20 3:43 AM, Vladimir Sementsov-Ogievskiy wrote:
Bitmaps data is not critical, and we should not fail the migration (or
use postcopy recovering) because of dirty-bitmaps migration failure.
Instead we should just lose unfinished bitmaps.

Still we have to report io stream violation errors, as they affect the
whole migration stream.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
  migration/block-dirty-bitmap.c | 152 +++++++++++++++++++++++++--------
  1 file changed, 117 insertions(+), 35 deletions(-)

@@ -650,15 +695,32 @@ static int dirty_bitmap_load_bits(QEMUFile *f, 
DBMLoadState *s)
-        bdrv_dirty_bitmap_deserialize_zeroes(s->bitmap, first_byte, nr_bytes,
-                                             false);
+        if (!s->cancelled) {
+            bdrv_dirty_bitmap_deserialize_zeroes(s->bitmap, first_byte,
+                                                 nr_bytes, false);
+        }
      } else {
          size_t ret;
          uint8_t *buf;
          uint64_t buf_size = qemu_get_be64(f);

Pre-existing, but if I understand, we are reading a value from the migration stream...

-        uint64_t needed_size =
-            bdrv_dirty_bitmap_serialization_size(s->bitmap,
-                                                 first_byte, nr_bytes);
+        uint64_t needed_size;
+        buf = g_malloc(buf_size);
+        ret = qemu_get_buffer(f, buf, buf_size);

...and using it to malloc memory. Is that a potential risk of a malicious stream causing us to allocate too much memory in relation to the guest's normal size? If so, fixing that should be done separately.

I'm not a migration expert, but the patch looks reasonable to me.

Reviewed-by: Eric Blake <eblake@redhat.com>

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]