Hi all,

when you open an image [A] with a few more images on the backing chain
you get something like this:

    [E] <- [D] <- [C] <- [B] <- [A]

Here you can go from [A] to [E] by following the bs->backing
pointer. At the same time each one of the backing files has an
'inherits_from' attribute pointing to their parent, so you can go from
[E] to [A] following the inherits_from pointer.

'inherits_from' is used on bdrv_reopen_queue_child() to decide if a
node's children must be reopened together with the parent and inherit
its options.

If some the intermediate nodes are removed (either by block-stream or
by block-commit) you end up with something like this:

   [E] <- [A]

In this case we would expect [E] to inherit from [A], however its
inherits_from pointer is NULL and trying to change its options by
reopening [A] with backing.option=value fails.

This patch series fixes this. See each individual patch for more
details.

Regards,

Berto

Alberto Garcia (2):
  block: Update BlockDriverState.inherits_from on bdrv_set_backing_hd()
  block: Update BlockDriverState.inherits_from on
    bdrv_drop_intermediate()

 block.c                    |  37 ++++++++++++
 tests/qemu-iotests/161     | 137 +++++++++++++++++++++++++++++++++++++++++++++
 tests/qemu-iotests/161.out |  39 +++++++++++++
 tests/qemu-iotests/group   |   1 +
 4 files changed, 214 insertions(+)
 create mode 100755 tests/qemu-iotests/161
 create mode 100644 tests/qemu-iotests/161.out

-- 
2.11.0

ping

> Hi all,
>
> when you open an image [A] with a few more images on the backing chain
> you get something like this:
>
>     [E] <- [D] <- [C] <- [B] <- [A]
>
> Here you can go from [A] to [E] by following the bs->backing
> pointer. At the same time each one of the backing files has an
> 'inherits_from' attribute pointing to their parent, so you can go from
> [E] to [A] following the inherits_from pointer.
>
> 'inherits_from' is used on bdrv_reopen_queue_child() to decide if a
> node's children must be reopened together with the parent and inherit
> its options.
>
> If some the intermediate nodes are removed (either by block-stream or
> by block-commit) you end up with something like this:
>
>    [E] <- [A]
>
> In this case we would expect [E] to inherit from [A], however its
> inherits_from pointer is NULL and trying to change its options by
> reopening [A] with backing.option=value fails.
>
> This patch series fixes this. See each individual patch for more
> details.

Am 31.10.2018 um 17:16 hat Alberto Garcia geschrieben:
> Hi all,
> 
> when you open an image [A] with a few more images on the backing chain
> you get something like this:
> 
>     [E] <- [D] <- [C] <- [B] <- [A]
> 
> Here you can go from [A] to [E] by following the bs->backing
> pointer. At the same time each one of the backing files has an
> 'inherits_from' attribute pointing to their parent, so you can go from
> [E] to [A] following the inherits_from pointer.
> 
> 'inherits_from' is used on bdrv_reopen_queue_child() to decide if a
> node's children must be reopened together with the parent and inherit
> its options.
> 
> If some the intermediate nodes are removed (either by block-stream or
> by block-commit) you end up with something like this:
> 
>    [E] <- [A]
> 
> In this case we would expect [E] to inherit from [A], however its
> inherits_from pointer is NULL and trying to change its options by
> reopening [A] with backing.option=value fails.
> 
> This patch series fixes this. See each individual patch for more
> details.

Thanks, applied to the block branch.

Not a problem with the series, but I tried to run the test case without
the fix, and this is what I got:

-{"return": ""}
+{"return": "Cannot change the option 'backing.detect-zeroes'rn"}

Where does that final "rn" come from? Looks like we have a bug somewhere
in the error reporting code?

Kevin

On Thu 22 Nov 2018 06:52:00 PM CET, Kevin Wolf <kwolf@redhat.com> wrote:
> Not a problem with the series, but I tried to run the test case without
> the fix, and this is what I got:
>
> -{"return": ""}
> +{"return": "Cannot change the option 'backing.detect-zeroes'rn"}
>
> Where does that final "rn" come from? Looks like we have a bug
> somewhere in the error reporting code?

It looks like a \r\n that hasn't been properly interpreted as CRLF.

Berto