From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Na3im-0004XL-5q
	for qemu-devel@nongnu.org; Wed, 27 Jan 2010 03:57:56 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Na3ig-0004WL-34
	for qemu-devel@nongnu.org; Wed, 27 Jan 2010 03:57:55 -0500
Received: from [199.232.76.173] (port=55935 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Na3if-0004W2-8M
	for qemu-devel@nongnu.org; Wed, 27 Jan 2010 03:57:49 -0500
Received: from mx1.redhat.com ([209.132.183.28]:37998)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kwolf@redhat.com>) id 1Na3ie-00034W-N8
	for qemu-devel@nongnu.org; Wed, 27 Jan 2010 03:57:48 -0500
Message-ID: <4B5FFFCA.6090900@redhat.com>
Date: Wed, 27 Jan 2010 09:56:42 +0100
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH v2 01/10] qcow2: Fix error handling in
	qcow2_grow_l1_table
References: <1263996186-6623-1-git-send-email-kwolf@redhat.com>
	<1263996186-6623-2-git-send-email-kwolf@redhat.com>
	<4B5F60A3.6010205@linux.vnet.ibm.com>
In-Reply-To: <4B5F60A3.6010205@linux.vnet.ibm.com>
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: Anthony Liguori <aliguori@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org

Am 26.01.2010 22:37, schrieb Anthony Liguori:
> On 01/20/2010 08:02 AM, Kevin Wolf wrote:
>> Return the appropriate error value instead of always using EIO. Don't free the
>> L1 table on errors, we still need it.
>>
>> Signed-off-by: Kevin Wolf<kwolf@redhat.com>
>>    
> 
> Applied all.  Thanks.
> 
> Do you think this is stable-0.12 material?  Is there any reasonable 
> scenario where this could fix a user visible bug?

Yes, I think this is something for stable. Obviously the patches are
meant to only make a difference if something has gone wrong in the first
place, but in these cases it's expected to fix possible causes of
corruption (things like data written to clusters with refcount 0). Also
if someone relies on werror=enospc he'll need the right error codes.

Kevin