From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47673) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnsQN-0003Rl-5F for qemu-devel@nongnu.org; Mon, 10 Nov 2014 12:06:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XnsQG-00037S-Nm for qemu-devel@nongnu.org; Mon, 10 Nov 2014 12:06:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47243) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnsQG-000377-Fj for qemu-devel@nongnu.org; Mon, 10 Nov 2014 12:06:36 -0500 Message-ID: <5460F091.30906@redhat.com> Date: Mon, 10 Nov 2014 18:06:25 +0100 From: Max Reitz MIME-Version: 1.0 References: <1415627159-15941-1-git-send-email-mreitz@redhat.com> <1415627159-15941-10-git-send-email-mreitz@redhat.com> <5460EFDB.7030407@redhat.com> In-Reply-To: <5460EFDB.7030407@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 09/21] qcow2: Open images with refcount order != 4 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu-devel@nongnu.org Cc: Kevin Wolf , Peter Lieven , Stefan Hajnoczi On 2014-11-10 at 18:03, Eric Blake wrote: > On 11/10/2014 06:45 AM, Max Reitz wrote: >> No longer refuse to open images with a different refcount entry width >> than 16 bits; only reject images with a refcount width larger than 64 >> bits (which is prohibited by the specification). >> >> Signed-off-by: Max Reitz >> --- >> block/qcow2.c | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/block/qcow2.c b/block/qcow2.c >> index d70e927..b718e75 100644 >> --- a/block/qcow2.c >> +++ b/block/qcow2.c >> @@ -677,10 +677,10 @@ static int qcow2_open(BlockDriverState *bs, QDict *options, int flags, >> } >> >> /* Check support for various header values */ >> - if (header.refcount_order != 4) { >> - report_unsupported(bs, errp, "%d bit reference counts", >> - 1 << header.refcount_order); >> - ret = -ENOTSUP; >> + if (header.refcount_order > 6) { >> + error_setg(errp, "Reference count entry width too large (%i bit); may " >> + "not exceed 64 bit", 1 << header.refcount_order); > Overflows if I fuzz an image to put 32 or larger into > header.refcount_order. It may be better to just tweak the error message > to state that the order cannot exceed 6, rather than trying to display > the actual bit width that the user is requesting, as then you avoid the > '1 << problem'. Yes, probably. Or we display it in binary: "0b1%0*i", header.refcount_order, 0 (which works since refcount_order is guaranteed to exceed 6). Joking aside, yes, I'll omit the theoretical refcount width. Max