From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MvvEi-0000La-PR for qemu-devel@nongnu.org; Thu, 08 Oct 2009 11:49:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MvvEe-0000Ej-RD for qemu-devel@nongnu.org; Thu, 08 Oct 2009 11:49:00 -0400 Received: from [199.232.76.173] (port=42376 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MvvEe-0000EQ-MW for qemu-devel@nongnu.org; Thu, 08 Oct 2009 11:48:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34085) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MvvEe-00005w-54 for qemu-devel@nongnu.org; Thu, 08 Oct 2009 11:48:56 -0400 Message-ID: <4ACE09A3.9010909@redhat.com> Date: Thu, 08 Oct 2009 17:47:47 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qcow2: Bring synchronous read/write back to life References: <1255006928-7600-1-git-send-email-kwolf@redhat.com> <20091008152831.GC29691@shareable.org> In-Reply-To: <20091008152831.GC29691@shareable.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: qemu-devel@nongnu.org Am 08.10.2009 17:28, schrieb Jamie Lokier: > Kevin Wolf wrote: >> The original bdrv_read would mean that we read some data >> synchronously and that we won't be interrupted during this read. The >> latter assumption is no longer true with the emulation function >> which needs to use qemu_aio_poll and therefore allows the callback >> of any other concurrent AIO request to be run during the read. Which >> in turn means that (meta)data read earlier could have changed and be >> invalid now. > > I'm not sure if I understand your description, specifically > "(meta)data read earlier could have changed and be invalid now". > > Do you mean: No, it's not exactly what I meant. But you're right, your scenario could happen, too. If global state is changed in an AIO callback called during bdrv_read/write (e.g. a new L2 table is loaded into the cache), bad things are almost guaranteed to happen. What I was thinking of is: > > Async call into qcow2 #2 > ------------------------ > > issues a request with bdrv_read/write > > Async call into qcow2 #1 > ------------------------ > reads some metadata from memory (**) #1 reads some metadata from disk (from the image file) > does some calculations > issues a request with bdrv_read/write > > the request completes > updates some metadata in memory #2 updates the metadata in the file > async call finished with result > > the request completes > updates some metadata in memory > .... ERROR, memory isn't what it was at point (**) #1 still uses the old metadata which it had loaded into memory (specifically those parts on the stack). Also, I was thinking of #2 as being a regular AIO write (no bdrv_write involved), but again your version could work as well. As I said I don't know yet which of them really happens. Kevin