tree 823ea4e705913bc101d0b4c95572e1ac35d3df22
parent 8bfea15ddac3a0ae832f181653c36e020f24f007
author Kevin Wolf <kwolf@redhat.com> 1398422167 +0200
committer Kevin Wolf <kwolf@redhat.com> 1398848700 +0200

Revert "block: another bdrv_append fix"

This reverts commit 3a389e7926750cba5c83f662b1941888b2bebc04. The commit
was wrong and what it tried to fix just works today without any change.

What the commit tried to fix:

    When creating live snapshots, the new image file is opened with
    BDRV_O_NO_BACKING because the whole backing chain is already opened.
    It is then appended to the chain using bdrv_append(). The result of
    this was that the image had a backing file, but BDRV_O_NO_BACKING
    was still set. This is obviously inconsistent.

    There used to be some places in qemu that closed and image and then
    opened it again, with its old flags (a bdrv_open()/close() sequence
    involves reopening the whole backing file chain, too). In this case
    the BDRV_O_NO_BACKING flag meant that the backing chain wasn't
    reopened and only the top layer was left.

    (Most, but not all of these places are replaced by bdrv_reopen()
    today, which doesn't touch the backing files at all.)

    Other places that looked at bs->open_flags weren't interested in
    BDRV_O_NO_BACKING, so no breakage there.

What it actually did:

    The commit moved the BDRV_O_NO_BACKING away to the backing file.
    Because the bdrv_open()/close() sequences only looked at the flags
    of the top level BlockDriverState and used it for the whole chain,
    the flag didn't hurt there any more. Obviously, it is still
    inconsistent because the backing file may have another backing file,
    but without practical impact.

    At the same time, it swapped all other flags. This is practically
    irrelevant as long as live snapshots only allow opening the new
    layer with the same flags as the old top layer. It still doesn't
    make any sense, and it is a time bomb that explodes as soon as the
    flags can differ.

    bdrv_append_temp_snapshot() is such a case: It adds the new flag
    BDRV_O_TEMPORARY for the temporary snapshot. The swapping of commit
    3a389e79 results in the following nonsensical configuration:

    bs->open_flags:                     BDRV_O_TEMPORARY cleared
    bs->file->open_flags:               BDRV_O_TEMPORARY set
    bs->backing_hd->open_flags:         BDRV_O_TEMPORARY set
    bs->backing_hd->file->open_flags:   BDRV_O_TEMPORARY cleared

    We're still lucky because the format layer ignores the flag and the
    protocol layer happens to get the right value, but sooner or later
    this is bound to go wrong...

What the right fix would have been:

    Simply clear the BDRV_O_NO_BACKING flag when the BlockDriverState is
    appended to an existing backing file chain, because now it does have
    a backing file.

    Commit 4ddc07ca already implemented this silently in bdrv_append(),
    so we don't have to come up with a new fix.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>