diff options
author | Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> | 2019-09-27 15:23:52 +0300 |
---|---|---|
committer | John Snow <jsnow@redhat.com> | 2019-10-17 17:02:32 -0400 |
commit | 644ddbb7540cfb69941f33629281819f53770666 (patch) | |
tree | 4b418533bc83ae4ae272c888dc1256dd41b87d47 /hw/dma/i8257.c | |
parent | bd429a884cebde851e0fcfd144a8f8ca7185bd09 (diff) | |
download | qemu-644ddbb7540cfb69941f33629281819f53770666.zip qemu-644ddbb7540cfb69941f33629281819f53770666.tar.gz qemu-644ddbb7540cfb69941f33629281819f53770666.tar.bz2 |
block/qcow2-bitmap: do not remove bitmaps on reopen-ro
qcow2_reopen_bitmaps_ro wants to store bitmaps and then mark them all
readonly. But the latter don't work, as
qcow2_store_persistent_dirty_bitmaps removes bitmaps after storing.
It's OK for inactivation but bad idea for reopen-ro. And this leads to
the following bug:
Assume we have persistent bitmap 'bitmap0'.
Create external snapshot
bitmap0 is stored and therefore removed
Commit snapshot
now we have no bitmaps
Do some writes from guest (*)
they are not marked in bitmap
Shutdown
Start
bitmap0 is loaded as valid, but it is actually broken! It misses
writes (*)
Incremental backup
it will be inconsistent
So, let's stop removing bitmaps on reopen-ro. But don't rejoice:
reopening bitmaps to rw is broken too, so the whole scenario will not
work after this patch and we can't enable corresponding test cases in
260 iotests still. Reopening bitmaps rw will be fixed in the following
patches.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 20190927122355.7344-7-vsementsov@virtuozzo.com
Signed-off-by: John Snow <jsnow@redhat.com>
Diffstat (limited to 'hw/dma/i8257.c')
0 files changed, 0 insertions, 0 deletions