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 <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. > > 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? 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... Kevin