Hi, looks like we have a bug in the bdrv_reopen() code.
It turns out that 'block-commit' fails if the 'top' node is not the
active layer or its immediate backing file, and none of our test cases
has detected that. I'm attaching one that reproduces the problem.
What happens is that 'block-commit' reopens the overlay of the top
node in read-write mode in order to update the backing file string. In
addition to that, the 'base' image also needs to be reopened in r/w.
Here's the relevant code from commit_start():
if (!(orig_base_flags & BDRV_O_RDWR)) {
reopen_queue = bdrv_reopen_queue(reopen_queue, base, NULL,
orig_base_flags | BDRV_O_RDWR);
}
if (!(orig_overlay_flags & BDRV_O_RDWR)) {
reopen_queue = bdrv_reopen_queue(reopen_queue, overlay_bs, NULL,
orig_overlay_flags | BDRV_O_RDWR);
}
if (reopen_queue) {
bdrv_reopen_multiple(reopen_queue, &local_err);
/*...*/
}
'base' is reopened first in r/w mode, then 'overlay_bs'. However it
seems that the latter has the side effect or reopening 'base' again in
read-only mode, therefore the job ends up failing with -EPERM.
Just swapping the order of the bdrv_reopen_queue() calls is enough to
fix the problem, but I'm sure this needs deeper changes in the
bdrv_reopen() code instead.
Berto
Alberto Garcia (1):
qemu-iotests: Test the reopening of overlay_bs in 'block-commit'
tests/qemu-iotests/040 | 30 ++++++++++++++++++++++++++++++
tests/qemu-iotests/040.out | 4 ++--
2 files changed, 32 insertions(+), 2 deletions(-)
--
2.6.1
