Re: [Qemu-devel] [PATCH] block: fix backing file segfault

[Max Reitz <mreitz@redhat.com>]

On 10.01.2014 18:55, Kevin Wolf wrote:
> Am 10.01.2014 um 18:27 hat Max Reitz geschrieben:
>> On 09.01.2014 11:59, Kevin Wolf wrote:
>>> [ 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 <peter@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.
>> bs->backing_hd->filename would be set by the bdrv_open_common() in
>> bdrv_open(), the filename is read from file->filename (if file !=
>> NULL; in this case, that would be bs->backing_hd->file->filename) or
>> from the configuration option "filename".
>>
>> The latter configuration option is not used by
>> bdrv_open_backing_file(), as far as I can see. However,
>> bs->backing_hd->file->filename is exactly the field the old code
>> uses, therefore, using bs->backing_hd->filename directly should not
>> break anything.
>>
>> However, the patch does something different: If file is NULL, it
>> leaves bs->backing_file unchanged; whereas using
>> bs->backing_hd->filename would in this case result in the value of
>> the "filename" option. I think leaving bs->backing_file unchanged is
>> probably better, unless it is "" and the "filename" option is set.
>>
>> If we want bs->backing_hd->filename to always point to a valid
>> filename, we'd probably have to copy to contents of bs->backing_file
>> there at some point in time, if it is not valid. But this is exactly
>> a point in code where bs->backing_file is updated, so there'd be no
>> gain if we instead updated bs->backing_hd->filename if necessary and
>> then copied that to bs->backing_file, as long as there is no other
>> place in the code where bs->backing_hd->filename always has to be a
>> valid filename.
>>
>> Thus, I think the patch is okay, but I'd probably prefer "if
>> (bs->backing_hd->filename[0]) pstrcpy(...,
>> bs->backing_hd->filename);" - although that should not differ from
>> the given patch, unless the "filename" option is set for the
>> backing_hd.
> Ok, if you're happy with it, I'll apply it. Can I put your Reviewed-by
> there?

Yes, feel free to.

> In the long run, we need to get rid of all this copying anyway. I'm
> imagining a BlockDriver function that returns a file name to reproduce
> the same setup, and a removal of bs->backing_file and bs->file_name.
>
> For some drivers, the returned filename would be a URL or some other
> string that that particular driver can parse.
>
> While doing that, we might also consider a fake protocol that handles
> filenames like 'json:{"driver":"qcow2","lazy-refcounts":"on",...}',
> because for some drivers this might be the only thing that comes close
> to a filename as it is a single string at least...

Urgh. *g*

I'm not sure if we should force every BDS to have a clearly defining 
file name. If there are options, which completely change the behavior of 
the block driver (I wouldn't consider lazy-refcounts one of them since 
it doesn't change the contents of the block device), I'd rather return 
NULL when asked for a file name. But then again, maybe an ugly filename 
is better than none at all…

In general, I'd prefer abandoning filenames* (especially protocol 
filenames) altogether. The set of options with which to recreate the 
same BDS is already available.

Max


*Of course, we need filenames for, well, opening files, but I'm 
referring to have an explicit string "filename" in addition to the 
option dicts (nearly) everywhere. And as far as I see it, we don't 
really want the user to specify a filename outside of the options 
anymore anyway, therefore we should probably not encourage him/her to do 
so by introducing filename abominations which may contain all options. ;-)