From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M1yQw-0002Ru-H5 for qemu-devel@nongnu.org; Thu, 07 May 2009 03:54:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M1yQs-0002Rh-3s for qemu-devel@nongnu.org; Thu, 07 May 2009 03:54:22 -0400 Received: from [199.232.76.173] (port=38667 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1yQr-0002Re-UZ for qemu-devel@nongnu.org; Thu, 07 May 2009 03:54:17 -0400 Received: from mx20.gnu.org ([199.232.41.8]:54969) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M1yQq-0006zw-P1 for qemu-devel@nongnu.org; Thu, 07 May 2009 03:54:17 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M1yQj-0001pS-Lx for qemu-devel@nongnu.org; Thu, 07 May 2009 03:54:09 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n477s7M5027605 for ; Thu, 7 May 2009 03:54:07 -0400 Message-ID: <4A02939C.8020106@redhat.com> Date: Thu, 07 May 2009 10:54:04 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] qcow2/virtio corruption: Don't allocate the same cluster twice References: <1241627950-22195-1-git-send-email-kwolf@redhat.com> <4A01C0C6.7020902@redhat.com> <4A01C2D4.5070000@redhat.com> <4A01C411.3060505@redhat.com> <4A01CE6C.3000901@redhat.com> <20090507073237.GY9795@redhat.com> In-Reply-To: <20090507073237.GY9795@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Kevin Wolf , markmc@redhat.com, qemu-devel@nongnu.org Gleb Natapov wrote: > > The reason we need to copy unmodified sectors in alloc_cluster_link_l2() > is exactly to handle concurrent writes into the same cluster. This is > essentially RMW. I don't see why concurrent writes should not work with > the logic in place. There is a bug there currently of cause :) Can > somebody check this patch: > > > diff --git a/block-qcow2.c b/block-qcow2.c > index 7840634..801d26d 100644 > --- a/block-qcow2.c > +++ b/block-qcow2.c > @@ -995,8 +995,8 @@ static int alloc_cluster_link_l2(BlockDriverState *bs, uint64_t cluster_offset, > if(l2_table[l2_index + i] != 0) > old_cluster[j++] = l2_table[l2_index + i]; > > - l2_table[l2_index + i] = cpu_to_be64((cluster_offset + > - (i << s->cluster_bits)) | QCOW_OFLAG_COPIED); > + l2_table[l2_index + i] = cpu_to_be64(((cluster_offset + > + (i << s->cluster_bits)) | QCOW_OFLAG_COPIED)); > } > > if (bdrv_pwrite(s->hd, l2_offset + l2_index * sizeof(uint64_t), > @@ -1005,7 +1005,8 @@ static int alloc_cluster_link_l2(BlockDriverState *bs, uint64_t cluster_offset, > goto err; > > for (i = 0; i < j; i++) > - free_any_clusters(bs, be64_to_cpu(old_cluster[i]), 1); > + free_any_clusters(bs, be64_to_cpu(old_cluster[i]) & ~QCOW_OFLAG_COPIED, > + 1); > > ret = 0; > err: > I can confirm that it fixes the problem. -- error compiling committee.c: too many arguments to function