From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NUjF3-00016b-1F
	for qemu-devel@nongnu.org; Tue, 12 Jan 2010 11:05:13 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NUjEy-0000wo-WB
	for qemu-devel@nongnu.org; Tue, 12 Jan 2010 11:05:12 -0500
Received: from [199.232.76.173] (port=32858 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NUjEx-0000vt-Ue
	for qemu-devel@nongnu.org; Tue, 12 Jan 2010 11:05:08 -0500
Received: from mx1.redhat.com ([209.132.183.28]:38588)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kwolf@redhat.com>) id 1NUjEx-0007wy-2B
	for qemu-devel@nongnu.org; Tue, 12 Jan 2010 11:05:07 -0500
Message-ID: <4B4C9D70.2090506@redhat.com>
Date: Tue, 12 Jan 2010 17:04:00 +0100
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 1/2] block: clean up bdrv_open2 structure
	a bit
References: <20100111175137.GA7571@lst.de>
In-Reply-To: <20100111175137.GA7571@lst.de>
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.gnu.org/pipermail/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: Christoph Hellwig <hch@lst.de>
Cc: qemu-devel@nongnu.org

Am 11.01.2010 18:51, schrieb Christoph Hellwig:
> Check the whitelist as early as possible instead of continuing the
> setup, and move all the error handling code to the end of the
> function.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> Index: qemu/block.c
> ===================================================================
> --- qemu.orig/block.c	2010-01-11 17:48:27.811004054 +0100
> +++ qemu/block.c	2010-01-11 17:52:15.578006158 +0100
> @@ -428,10 +428,16 @@ int bdrv_open2(BlockDriverState *bs, con
>              drv = find_image_format(filename);
>          }
>      }
> +
>      if (!drv) {
>          ret = -ENOENT;
>          goto unlink_and_fail;
>      }
> +    if (use_bdrv_whitelist && !bdrv_is_whitelisted(drv)) {
> +        ret = -ENOTSUP;
> +        goto unlink_and_fail;
> +    }
> +
>      bs->drv = drv;
>      bs->opaque = qemu_mallocz(drv->instance_size);
>  
> @@ -452,23 +458,17 @@ int bdrv_open2(BlockDriverState *bs, con
>              (flags & (BDRV_O_CACHE_MASK|BDRV_O_NATIVE_AIO));
>      else
>          open_flags = flags & ~(BDRV_O_FILE | BDRV_O_SNAPSHOT);
> -    if (use_bdrv_whitelist && !bdrv_is_whitelisted(drv))
> -        ret = -ENOTSUP;
> -    else
> -        ret = drv->bdrv_open(bs, filename, open_flags);
> +
> +    ret = drv->bdrv_open(bs, filename, open_flags);
>      if ((ret == -EACCES || ret == -EPERM) && !(flags & BDRV_O_FILE)) {
>          ret = drv->bdrv_open(bs, filename, open_flags & ~BDRV_O_RDWR);
>          bs->read_only = 1;
>      }
> +
>      if (ret < 0) {
> -        qemu_free(bs->opaque);
> -        bs->opaque = NULL;
> -        bs->drv = NULL;
> -    unlink_and_fail:
> -        if (bs->is_temporary)
> -            unlink(filename);
> -        return ret;
> +        goto free_and_fail;
>      }
> +
>      if (drv->bdrv_getlength) {
>          bs->total_sectors = bdrv_getlength(bs) >> BDRV_SECTOR_BITS;
>      }
> @@ -502,6 +502,15 @@ int bdrv_open2(BlockDriverState *bs, con
>              bs->change_cb(bs->change_opaque);
>      }
>      return 0;
> +
> +free_and_fail:
> +    qemu_free(bs->opaque);
> +    bs->opaque = NULL;
> +    bs->drv = NULL;
> +unlink_and_fail:

To keep the behaviour as previously you'd need to set at least bs->drv
in the unlink_and_fail case, too. I have no clue why it's important to
set it to NULL when bs isn't going to be used anyway (probably it is,
but I don't know where), but Fabrice committed this in 6b21b973 as a
fix. Unfortunately, the commit message looks like most of Fabrice's
commit messages, so it's of no use for me...

Kevin