From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34414) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ1cz-0004s2-1S for qemu-devel@nongnu.org; Wed, 04 Feb 2015 10:12:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJ1cw-0000Gh-B6 for qemu-devel@nongnu.org; Wed, 04 Feb 2015 10:12:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37985) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ1cw-0000GW-4J for qemu-devel@nongnu.org; Wed, 04 Feb 2015 10:12:26 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t14FCPYZ007015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 4 Feb 2015 10:12:25 -0500 Date: Wed, 4 Feb 2015 16:12:23 +0100 From: Kevin Wolf Message-ID: <20150204151223.GE5641@noname.redhat.com> References: <1418647857-3589-1-git-send-email-mreitz@redhat.com> <1418647857-3589-8-git-send-email-mreitz@redhat.com> <20150204114015.GA5641@noname.redhat.com> <54D23505.9000703@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54D23505.9000703@redhat.com> Subject: Re: [Qemu-devel] [PATCH v5 07/26] qcow2: Respect error in qcow2_alloc_bytes() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: qemu-devel@nongnu.org, Stefan Hajnoczi Am 04.02.2015 um 16:04 hat Max Reitz geschrieben: > On 2015-02-04 at 06:40, Kevin Wolf wrote: > >Am 15.12.2014 um 13:50 hat Max Reitz geschrieben: > >>qcow2_update_cluster_refcount() may fail, and qcow2_alloc_bytes() should > >>mind that case. > >> > >>Signed-off-by: Max Reitz > >>Reviewed-by: Eric Blake > >>Reviewed-by: Stefan Hajnoczi > >>--- > >> block/qcow2-refcount.c | 33 +++++++++++++++++++++------------ > >> 1 file changed, 21 insertions(+), 12 deletions(-) > >> > >>diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c > >>index 0308a7e..db81647 100644 > >>--- a/block/qcow2-refcount.c > >>+++ b/block/qcow2-refcount.c > >>@@ -778,8 +778,8 @@ int qcow2_alloc_clusters_at(BlockDriverState *bs, uint64_t offset, > >> int64_t qcow2_alloc_bytes(BlockDriverState *bs, int size) > >> { > >> BDRVQcowState *s = bs->opaque; > >>- int64_t offset, cluster_offset; > >>- int free_in_cluster; > >>+ int64_t offset, cluster_offset, new_cluster; > >>+ int free_in_cluster, ret; > >> BLKDBG_EVENT(bs->file, BLKDBG_CLUSTER_ALLOC_BYTES); > >> assert(size > 0 && size <= s->cluster_size); > >>@@ -800,23 +800,32 @@ int64_t qcow2_alloc_bytes(BlockDriverState *bs, int size) > >> free_in_cluster -= size; > >> if (free_in_cluster == 0) > >> s->free_byte_offset = 0; > >>- if (offset_into_cluster(s, offset) != 0) > >>- qcow2_update_cluster_refcount(bs, offset >> s->cluster_bits, 1, > >>- false, QCOW2_DISCARD_NEVER); > >>+ if (offset_into_cluster(s, offset) != 0) { > >>+ ret = qcow2_update_cluster_refcount(bs, offset >> s->cluster_bits, > >>+ 1, false, QCOW2_DISCARD_NEVER); > >>+ if (ret < 0) { > >>+ return ret; > >Not sure how relevant it is, but s->free_byte_offset has already been > >increased, so we're leaving sub-cluster space unused. (It's not really > >leaking as freeing all references still frees the cluster.) > > Right, will fix. > > >>+ } > >>+ } > >> } else { > >>- offset = qcow2_alloc_clusters(bs, s->cluster_size); > >>- if (offset < 0) { > >>- return offset; > >>+ new_cluster = qcow2_alloc_clusters(bs, s->cluster_size); > >>+ if (new_cluster < 0) { > >>+ return new_cluster; > >> } > >offset is the return value of this function, and now there are cases > >where it isn't set to new_cluster any more (I wonder why gcc doesn't > >warn). > > Because @offset is always set. In case the next condition is true, > it is set to s->free_byte_offset, just like it was before. In case > it isn't, s->free_byte_offset will be set to @new_cluster and the > loop will be started again (probably always resulting in size <= > free_in_cluster being true and thus @offset being set to > s->free_byte_offset). Yes, I misread. Hooray for goto. One more reason for a cleanup of the whole function. Kevin