[ CCing Max, who was recently active in this area, for another opinion ]

Am 08.01.2014 um 20:43 hat Peter Feiner geschrieben:
> When a backing file is opened such that (1) a protocol is directly
> used as the block driver and (2) the block driver has bdrv_file_open,
> bdrv_open_backing_file segfaults. The problem arises because
> bdrv_open_common returns without setting bd->backing_hd->file.
> 
> To effect (1), you seem to have to use the -F flag in qemu-img. There
> are several block drivers that satisfy (2), such as "file" and "nbd".
> Here are some concrete examples:
> 
>     #!/bin/bash
> 
>     echo Test file format
>     ./qemu-img create -f file base.file 1m
>     ./qemu-img create -f qcow2 -F file -o backing_file=base.file\
>         file-overlay.qcow2
>     ./qemu-img convert -O raw file-overlay.qcow2 file-convert.raw
> 
>     echo Test nbd format
>     SOCK=$PWD/nbd.sock
>     ./qemu-img create -f raw base.raw 1m
>     ./qemu-nbd -t -k $SOCK base.raw &
>     trap "kill $!" EXIT
>     while ! test -e $SOCK; do sleep 1; done
>     ./qemu-img create -f qcow2 -F nbd -o backing_file=nbd:unix:$SOCK\
>         nbd-overlay.qcow2
>     ./qemu-img convert -O raw nbd-overlay.qcow2 nbd-convert.raw
> 
> Without this patch, the two qemu-img convert commands segfault.
> 
> This is a regression that was introduced in v1.7 by
> dbecebddfa4932d1c83915bcb9b5ba5984eb91be.
> 
> Signed-off-by: Peter Feiner <pe...@gridcentric.ca>
> ---
>  block.c |    5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/block.c b/block.c
> index 64e7d22..a4a172d 100644
> --- a/block.c
> +++ b/block.c
> @@ -1016,8 +1016,9 @@ int bdrv_open_backing_file(BlockDriverState *bs, QDict 
> *options, Error **errp)
>          error_free(local_err);
>          return ret;
>      }
> -    pstrcpy(bs->backing_file, sizeof(bs->backing_file),
> -            bs->backing_hd->file->filename);
> +    if (bs->backing_hd->file)
> +        pstrcpy(bs->backing_file, sizeof(bs->backing_file),
> +                bs->backing_hd->file->filename);
>      return 0;
>  }

I think if there is no bs->backing_hd->file, we should get the filename
from bs->backing_hd->filename instead of leaving it empty.

In fact, can we always do that or does bs->backing_hd normally lack the
filename? If so, perhaps that is what we need to fix, so we can always
directly use bs->backing_hd->filename here.

Kevin

Reply via email to