From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53690) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1fqg-0008OP-5d for qemu-devel@nongnu.org; Fri, 10 Jan 2014 12:26:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1fqb-0002gY-7h for qemu-devel@nongnu.org; Fri, 10 Jan 2014 12:26:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:21904) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1fqa-0002gO-Vn for qemu-devel@nongnu.org; Fri, 10 Jan 2014 12:26:17 -0500 Message-ID: <52D02D96.3010901@redhat.com> Date: Fri, 10 Jan 2014 18:27:50 +0100 From: Max Reitz MIME-Version: 1.0 References: <1389210205-10787-1-git-send-email-peter@gridcentric.ca> <20140109105930.GA2862@dhcp-200-207.str.redhat.com> In-Reply-To: <20140109105930.GA2862@dhcp-200-207.str.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] block: fix backing file segfault List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf , Peter Feiner Cc: famz@redhat.com, qemu-devel@nongnu.org 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 >> --- >> 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. Max