From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NUkGC-0005T7-Gd
	for qemu-devel@nongnu.org; Tue, 12 Jan 2010 12:10:28 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NUkG7-0005Pi-NT
	for qemu-devel@nongnu.org; Tue, 12 Jan 2010 12:10:27 -0500
Received: from [199.232.76.173] (port=51932 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NUkG7-0005PX-CJ
	for qemu-devel@nongnu.org; Tue, 12 Jan 2010 12:10:23 -0500
Received: from mx20.gnu.org ([199.232.41.8]:15093)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <hch@lst.de>) id 1NUkG6-00020f-7q
	for qemu-devel@nongnu.org; Tue, 12 Jan 2010 12:10:22 -0500
Received: from verein.lst.de ([213.95.11.210])
	by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from <hch@lst.de>)
	id 1NUkFA-0003jV-S9
	for qemu-devel@nongnu.org; Tue, 12 Jan 2010 12:09:25 -0500
Date: Tue, 12 Jan 2010 18:09:05 +0100
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [PATCH 1/2] block: clean up bdrv_open2 structure a
	bit
Message-ID: <20100112170905.GA31233@lst.de>
References: <20100111175137.GA7571@lst.de> <4B4C9D70.2090506@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B4C9D70.2090506@redhat.com>
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: Kevin Wolf <kwolf@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>, qemu-devel@nongnu.org

On Tue, Jan 12, 2010 at 05:04:00PM +0100, Kevin Wolf wrote:
> 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...

The unlink_and_fail label can only be reached from places where we
haven't set bs->drv yet, so it should be fine.