From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:52159)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1UeoFK-0000KS-Mz
	for qemu-devel@nongnu.org; Tue, 21 May 2013 11:13:08 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1UeoFE-0002Lk-0U
	for qemu-devel@nongnu.org; Tue, 21 May 2013 11:13:02 -0400
Received: from mx1.redhat.com ([209.132.183.28]:40631)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1UeoFD-0002LT-PV
	for qemu-devel@nongnu.org; Tue, 21 May 2013 11:12:55 -0400
Message-ID: <519B8EBD.6030006@redhat.com>
Date: Tue, 21 May 2013 17:11:57 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1368628476-19622-1-git-send-email-stefanha@redhat.com>
	<1368628476-19622-3-git-send-email-stefanha@redhat.com>
	<519A095D.4070808@redhat.com>
	<20130521133428.GA6631@stefanha-thinkpad.muc.redhat.com>
In-Reply-To: <20130521133428.GA6631@stefanha-thinkpad.muc.redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v3 2/8] block: add basic backup support to
 block driver
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: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Fam Zheng <famz@redhat.com>, qemu-devel@nongnu.org, xiawenc@linux.vnet.ibm.com, imain@redhat.com, Stefan Hajnoczi <stefanha@redhat.com>, dietmar@proxmox.com

Il 21/05/2013 15:34, Stefan Hajnoczi ha scritto:
> /**
>  * hbitmap_iter_init:
> [...]
>  * position of the iterator is also okay.  However, concurrent resetting of
>  * bits can lead to unexpected behavior if the iterator has not yet reached
>  * those bits. 
>  */ 
> void hbitmap_iter_init(HBitmapIter *hbi, const HBitmap *hb, uint64_t first);
> 
> This worries me.  We would initialize the bitmap to all 1s.  Backing up
> a cluster resets the bit.  But the documentation says it is not safe to
> reset bits while iterating?

Hmm, right.  But do we need the bitmap at all?  We can just use
bdrv_is_allocated like bdrv_co_do_readv does.

The code has a comment:

> +        /* immediately set bitmap (avoid coroutine race) */
> +        hbitmap_set(job->bitmap, start, 1);

but wouldn't this be avoided anyway, because of the mutual exclusion
between overlapping requests?

Paolo