From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UmiK8-0002mc-W3 for qemu-devel@nongnu.org; Wed, 12 Jun 2013 06:30:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UmiK7-00077h-GD for qemu-devel@nongnu.org; Wed, 12 Jun 2013 06:30:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8471) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UmiK7-00077R-4i for qemu-devel@nongnu.org; Wed, 12 Jun 2013 06:30:39 -0400 Date: Wed, 12 Jun 2013 12:30:27 +0200 From: Kevin Wolf Message-ID: <20130612103027.GB2677@dhcp-200-207.str.redhat.com> References: <1371024284-3572-1-git-send-email-evgeny.budilovsky@ravellosystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1371024284-3572-1-git-send-email-evgeny.budilovsky@ravellosystems.com> Subject: Re: [Qemu-devel] [PATCH] allow reading variable size vmdk descriptor files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Evgeny Budilovsky Cc: qemu-devel@nongnu.org, Stefan Hajnoczi Am 12.06.2013 um 10:04 hat Evgeny Budilovsky geschrieben: > The hard-coded 2k buffer on the stack won't allow reading big descriptor > files which can be generated when storing big images (For example 500G > vmdk splitted to 2G chunks). > > Signed-off-by: Evgeny Budilovsky > --- > block/vmdk.c | 28 +++++++++++++++++++++------- > 1 file changed, 21 insertions(+), 7 deletions(-) > > diff --git a/block/vmdk.c b/block/vmdk.c > index 608daaf..1bc944b 100644 > --- a/block/vmdk.c > +++ b/block/vmdk.c > @@ -719,27 +719,41 @@ static int vmdk_open_desc_file(BlockDriverState *bs, int flags, > int64_t desc_offset) > { > int ret; > - char buf[2048]; > + char *buf = NULL; > char ct[128]; > BDRVVmdkState *s = bs->opaque; > + int64_t size; > > - ret = bdrv_pread(bs->file, desc_offset, buf, sizeof(buf)); > + size = bdrv_get_allocated_file_size(bs); > + if (size < 0) { > + return -EINVAL; > + } > + > + buf = g_malloc0(size+1); This is an unbounded allocation. Not sure if this is a good idea. Can we restrict the maximum size to something reasonably small, like a megabyte? Kevin