qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Stefan Weil <sw@weilnetz.de>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] block/vdi: Fix locking for parallel requests
Date: Wed, 18 Feb 2015 10:09:43 -0500	[thread overview]
Message-ID: <54E4AB37.2000802@redhat.com> (raw)
In-Reply-To: <20150218123938.GD4996@noname.str.redhat.com>

On 2015-02-18 at 07:39, Kevin Wolf wrote:
> Am 17.02.2015 um 22:33 hat Max Reitz geschrieben:
>> Concurrently modifying the bmap is not a good idea;
> Why? I mean, the fact that this fixes something for you probably means
> that there really is some piece of local state that is invalidated by
> concurrent writes, but it's not obvious to me what it is.

One thing I can see is the following: The write operations for header 
and bmap are separate. Therefore, writing the header may succeed; then, 
when writing the bmap, something may yield and another instance of 
vdi_co_write() gets to run. That instance is still in the while loop, 
allocating a new block.

It modifies s->bmap[] and increases s->header.blocks_allocated; then 
tries to write. That yields and the first coroutine wakes up. It writes 
the bmap to the disk, which is now inconsistent with 
s->header.blocks_allocated, though. So that looks to me like it may 
break, although it in fact doesn't seem to be responsible for the 
problem at hand.

For that problem, always doing the unlock() after the bdrv_write() in 
the "if (!VDI_IS_ALLOCATED(bmap_entry))" path seems enough; although I 
cannot really explain how coroutines yielding from writing the data 
block interferes with other coroutines allocating new blocks.

However, in case you agree with my reasoning for the possible corruption 
(which I did not try to produce), this patch (which would fix that) 
would also happen to prevent the really appearing VDI problems, so...

Max

> What could obviously happen is that metadata is written before the data
> is on the disk, but as we don't support backing files for VDI, this is
> irrelvant. (And if it were relevant, it stil wouldn't be fixed by your
> patch because the driver never flushes.)
>
>> this patch adds a
>> lock for it. See https://bugs.launchpad.net/qemu/+bug/1422307 for what
>> can go wrong without.
>>
>> Signed-off-by: Max Reitz <mreitz@redhat.com>
> Kevin

  reply	other threads:[~2015-02-18 15:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-17 21:33 [Qemu-devel] [PATCH] block/vdi: Fix locking for parallel requests Max Reitz
2015-02-17 21:49 ` Paolo Bonzini
2015-02-17 21:49   ` Max Reitz
2015-02-18  7:52 ` Paolo Bonzini
2015-02-18 15:10   ` Max Reitz
2015-02-18 12:39 ` Kevin Wolf
2015-02-18 15:09   ` Max Reitz [this message]
2015-02-27 11:25 ` Stefan Hajnoczi
2015-02-27 11:43   ` Kevin Wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54E4AB37.2000802@redhat.com \
    --to=mreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=sw@weilnetz.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).