From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:51793)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1V05CO-0001qz-6k
	for qemu-devel@nongnu.org; Fri, 19 Jul 2013 03:33:57 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1V05CM-0002Y9-O2
	for qemu-devel@nongnu.org; Fri, 19 Jul 2013 03:33:56 -0400
Received: from mail-wg0-x229.google.com ([2a00:1450:400c:c00::229]:47536)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1V05CM-0002Xw-Gn
	for qemu-devel@nongnu.org; Fri, 19 Jul 2013 03:33:54 -0400
Received: by mail-wg0-f41.google.com with SMTP id y10so264694wgg.0
	for <qemu-devel@nongnu.org>; Fri, 19 Jul 2013 00:33:53 -0700 (PDT)
Date: Fri, 19 Jul 2013 15:33:44 +0800
From: Stefan Hajnoczi <stefanha@gmail.com>
Message-ID: <20130719073344.GA9667@stefanha-thinkpad.redhat.com>
References: <1373992168-26043-1-git-send-email-pbonzini@redhat.com>
	<1373992168-26043-18-git-send-email-pbonzini@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1373992168-26043-18-git-send-email-pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 17/17] block: look for zero blocks in
 bs->file
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: famz@redhat.com, pl@kamp.de, qemu-devel@nongnu.org, stefanha@redhat.com

On Tue, Jul 16, 2013 at 06:29:28PM +0200, Paolo Bonzini wrote:
> diff --git a/block.c b/block.c
> index 557ce29..2d7d71f 100644
> --- a/block.c
> +++ b/block.c
> @@ -2977,7 +2977,7 @@ static int64_t coroutine_fn bdrv_co_get_block_status(BlockDriverState *bs,
>                                                       int nb_sectors, int *pnum)
>  {
>      int64_t n;
> -    int64_t ret;
> +    int64_t ret, ret2;
>  
>      if (sector_num >= bs->total_sectors) {
>          *pnum = 0;
> @@ -3003,6 +3003,14 @@ static int64_t coroutine_fn bdrv_co_get_block_status(BlockDriverState *bs,
>          ret |= BDRV_BLOCK_ZERO;
>      }
>  
> +    if (bs->file &&
> +        (ret & BDRV_BLOCK_DATA) && !(ret & BDRV_BLOCK_ZERO) &&
> +        (ret & BDRV_BLOCK_OFFSET_VALID)) {
> +        ret2 = bdrv_co_get_block_status(bs->file, ret >> BDRV_SECTOR_BITS,
> +                                        *pnum, pnum);
> +        ret |= (ret2 & BDRV_BLOCK_ZERO);
> +    }

This patch breaks qemu-iotests 030 (image streaming).

The problem is that bdrv_co_get_block_status() uses bs->total_sectors
directly instead of calling bdv_get_geometry()/bdrv_getlength().

With qcow2 the bs->file can grow on disk.  We don't update
bs->total_sectors.

Then this patch calls bdrv_co_get_block_status(bs->file) where we fail
with *pnum = 0, ret = 0 because bs->total_sectors suggests it is beyond
the end of the file.

The result is that 030 goes into an infinite loop.

As a quick test I switched the direct bs->total_sectors accesses to
bdrv_get_geometry() and it stopped hanging.  Perhaps the
bs->total_sectors caching needs to be improved though.

Stefan