qemu-block
[Top][All Lists]
Advanced

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

[Qemu-block] [PATCH 0/1] Test the reopening of overlay_bs in 'block-comm


From: Alberto Garcia
Subject: [Qemu-block] [PATCH 0/1] Test the reopening of overlay_bs in 'block-commit'
Date: Tue, 27 Oct 2015 18:43:41 +0200

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




reply via email to

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