From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34751) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1gQj-00008J-5x for qemu-devel@nongnu.org; Fri, 10 Jan 2014 13:03:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1gQe-0006Lp-0D for qemu-devel@nongnu.org; Fri, 10 Jan 2014 13:03:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49891) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1gQd-0006LJ-O6 for qemu-devel@nongnu.org; Fri, 10 Jan 2014 13:03:31 -0500 Message-ID: <52D03651.5010603@redhat.com> Date: Fri, 10 Jan 2014 19:05:05 +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> <52D02D96.3010901@redhat.com> <20140110175518.GG4276@dhcp-200-207.str.redhat.com> In-Reply-To: <20140110175518.GG4276@dhcp-200-207.str.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable 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 Cc: famz@redhat.com, Peter Feiner , qemu-devel@nongnu.org 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 opinio= n ] >>> >>> 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. Ther= e >>>> 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=3Dbase.file\ >>>> file-overlay.qcow2 >>>> ./qemu-img convert -O raw file-overlay.qcow2 file-convert.raw >>>> >>>> echo Test nbd format >>>> SOCK=3D$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=3Dnbd:unix:$S= OCK\ >>>> 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 *b= s, 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 filena= me >> >from bs->backing_hd->filename instead of leaving it empty. >>> In fact, can we always do that or does bs->backing_hd normally lack t= he >>> filename? If so, perhaps that is what we need to fix, so we can alway= s >>> 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 !=3D >> 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=20 file name. If there are options, which completely change the behavior of=20 the block driver (I wouldn't consider lazy-refcounts one of them since=20 it doesn't change the contents of the block device), I'd rather return=20 NULL when asked for a file name. But then again, maybe an ugly filename=20 is better than none at all=85 In general, I'd prefer abandoning filenames* (especially protocol=20 filenames) altogether. The set of options with which to recreate the=20 same BDS is already available. Max *Of course, we need filenames for, well, opening files, but I'm=20 referring to have an explicit string "filename" in addition to the=20 option dicts (nearly) everywhere. And as far as I see it, we don't=20 really want the user to specify a filename outside of the options=20 anymore anyway, therefore we should probably not encourage him/her to do=20 so by introducing filename abominations which may contain all options. ;-= )