From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=58424 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PnsiI-00044C-F1
	for qemu-devel@nongnu.org; Fri, 11 Feb 2011 08:07:07 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1PnsiE-00042N-95
	for qemu-devel@nongnu.org; Fri, 11 Feb 2011 08:07:06 -0500
Received: from mx1.redhat.com ([209.132.183.28]:18675)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1PnsiD-00042G-UE
	for qemu-devel@nongnu.org; Fri, 11 Feb 2011 08:07:02 -0500
Message-ID: <4D5534DD.6070705@redhat.com>
Date: Fri, 11 Feb 2011 14:08:45 +0100
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] xen_disk: cope with missing xenstore "params"
	node
References: <alpine.DEB.2.00.1102111232290.2826@kaball-desktop>
	<4D553042.4020502@redhat.com>
	<alpine.DEB.2.00.1102111250090.2826@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1102111250090.2826@kaball-desktop>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

Am 11.02.2011 13:59, schrieb Stefano Stabellini:
> On Fri, 11 Feb 2011, Kevin Wolf wrote:
>> Am 11.02.2011 13:38, schrieb Stefano Stabellini:
>>> When disk is a cdrom and the drive is empty the "params" node in
>>> xenstore might be missing completely: cope with it instead of
>>> segfaulting.
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>
>>>
>>> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
>>> index 134ac33..e553c4c 100644
>>> --- a/hw/xen_disk.c
>>> +++ b/hw/xen_disk.c
>>> @@ -577,12 +577,13 @@ static int blk_init(struct XenDevice *xendev)
>>>  {
>>>      struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev, xendev);
>>>      int index, qflags, have_barriers, info = 0;
>>> -    char *h;
>>> +    char *h = NULL;
>>>  
>>>      /* read xenstore entries */
>>>      if (blkdev->params == NULL) {
>>>  	blkdev->params = xenstore_read_be_str(&blkdev->xendev, "params");
>>> -        h = strchr(blkdev->params, ':');
>>> +        if (blkdev->params != NULL)
>>> +            h = strchr(blkdev->params, ':');
>>
>> The coding style requires braces here.
>>
> 
> Good point, I'll do.
> 
>>>  	if (h != NULL) {
>>>  	    blkdev->fileproto = blkdev->params;
>>>  	    blkdev->filename  = h+1;
>>
>> Let me add some more context:
>>
>>     if (h != NULL) {
>>         blkdev->fileproto = blkdev->params;
>>         blkdev->filename  = h+1;
>>         *h = 0;
>>     } else {
>>         blkdev->fileproto = "<unset>";
>>         blkdev->filename  = blkdev->params;
>>     }
>>
>> So in the NULL case we now have blkdev->filename = NULL. Doesn't this
>> just move the crash a few lines downwards when bdrv_open() tries to use
>> NULL as its filename?
> 
> There is a check on blkdev->params being NULL few lines after so we just
> return.

Thanks, I missed that one.

> Maybe an explicit return -1 like in the appended patch here would be
> better?
> diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> index 134ac33..fc0de14 100644
> --- a/hw/xen_disk.c
> +++ b/hw/xen_disk.c
> @@ -582,6 +582,9 @@ static int blk_init(struct XenDevice *xendev)
>      /* read xenstore entries */
>      if (blkdev->params == NULL) {
>  	blkdev->params = xenstore_read_be_str(&blkdev->xendev, "params");
> +        if (blkdev->params == NULL) {
> +            return -1;
> +        }
>          h = strchr(blkdev->params, ':');
>  	if (h != NULL) {
>  	    blkdev->fileproto = blkdev->params;

Yes, I think this is more explicit, and therefore easier to read.

Kevin