From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NHeU0-0007sC-BB
	for qemu-devel@nongnu.org; Mon, 07 Dec 2009 09:22:36 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NHeTs-0007hA-9U
	for qemu-devel@nongnu.org; Mon, 07 Dec 2009 09:22:32 -0500
Received: from [199.232.76.173] (port=36465 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NHeTs-0007gq-5T
	for qemu-devel@nongnu.org; Mon, 07 Dec 2009 09:22:28 -0500
Received: from qw-out-1920.google.com ([74.125.92.147]:24345)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1NHeTs-000271-1L
	for qemu-devel@nongnu.org; Mon, 07 Dec 2009 09:22:28 -0500
Received: by qw-out-1920.google.com with SMTP id 14so604833qwa.4
	for <qemu-devel@nongnu.org>; Mon, 07 Dec 2009 06:22:27 -0800 (PST)
Message-ID: <4B1D0FA0.8060500@codemonkey.ws>
Date: Mon, 07 Dec 2009 08:22:24 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks.
References: <20091204165301.GA4167@amd.home.annexia.org>
	<4B1943A0.7030509@codemonkey.ws>
	<20091204215517.GA5938@amd.home.annexia.org>
	<4B198D5B.5080803@codemonkey.ws> <4B1A98D9.7010408@redhat.com>
	<4B1A9C9F.5040705@codemonkey.ws>
	<20091207105855.GK23109@amd.home.annexia.org>
	<4B1D057F.9000708@codemonkey.ws>
	<20091207140857.GQ23109@amd.home.annexia.org>
In-Reply-To: <20091207140857.GQ23109@amd.home.annexia.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: Avi Kivity <avi@redhat.com>, qemu-devel@nongnu.org

Richard W.M. Jones wrote:
> On Mon, Dec 07, 2009 at 07:39:11AM -0600, Anthony Liguori wrote:
>   
>> Richard W.M. Jones wrote:
>>     
>>> Also if we only acquire the lock during the commit operation then
>>> we'll end up with disk corruption.
>>>       
>> Why do we end up with disk corruption?
>>     
>
> Forget about locking for a minute, I don't think this is safe
> currently.  If you have two VMs set up like:
>
>   qemu-img create -b backing.img foo.img
>   qemu-img create -b backing.img bar.img
>
>   qemu -drive file=foo.img     # VM1
>   qemu -drive file=bar.img     # VM2
>
> If VM1 does a commit to the backing image, then VM2 may be caching (in
> its kernel memory) bits of the old backing image, and will
> subsequently fetch bits of the new backing image, so it'll see a
> mixture of old and new data.  How is VM2 supposed to cope with this?
> It sounds like massive disk corruption to me ...
>   

Yes, this will cause corruption.  Implementing locking in the fashion 
I've previously described will prevent 'commit' from being run (since 
you can't upgrade the lock since someone else is holding a read-lock).

Regards,

Anthony Liguori