Re: [Qemu-devel] bug in reopen arch

[Kevin Wolf]

Am 12.06.2018 um 20:57 hat Vladimir Sementsov-Ogievskiy geschrieben:
> Hi all!
> 
> I've faced the following problem:
> 
>     1. create image with dirty bitmap, a.qcow2 (start qemu and run qmp
>     command block-dirty-bitmap-add)
> 
>     2. run the following commands:
> 
>         qemu-img create -f qcow2 -b a.qcow2 b.qcow2 10M
>         qemu-io -c 'write 0 512' b.qcow2
>         qemu-img commit b.qcow2
> 
>     3. last command fails with the following output:
> 
> Formatting 'b.qcow2', fmt=qcow2 size=68719476736 backing_file=a.qcow2
> cluster_size=65536 lazy_refcounts=off refcount_bits=16
> wrote 512/512 bytes at offset 0
> 512 bytes, 1 ops; 0.0953 sec (5.243 KiB/sec and 10.4867 ops/sec)
> qemu-img: #block397: Failed to make dirty bitmaps writable: Can't update
> bitmap directory: Operation not permitted
> qemu-img: Block job failed: Operation not permitted
> 
> And problem is that children are reopened _after_ parent. But qcow2 reopen
> needs write access to its file, to write IN_USE flag to dirty-bitmaps
> extension.

I was aware of a different instance of this problem: Assume a qcow2
image with an unknown autoclear flag (so it will be cleared on r/w
open), which is first opened r/o and then reopened r/w. This will fail
because .bdrv_reopen_prepare doesn't have the permissions yet.

Simply changing the order won't fix this because in the r/w -> r/o, the
driver will legitimately flush its caches in .bdrv_reopen_prepare, and
for this it still needs to be able to write.

We may need to have a way for nodes to access both the old and the new
state of their children. I'm not completely sure how to achieve this
best, though.

When I thought only of permissions, the obvious and simple thing to do
was to just get combined permissions for the old and new state, i.e.
'old_perm | new_perm' and 'old_shared & new_shared'. But I don't think
this is actually enough when the child node switches between a r/w and
a r/o file descriptor because even though QEMU's permission system would
allow the write, you still can't successfully write to a r/o file
descriptor.

Kevin