From: Stefan Weil <sw@weilnetz.de>
To: Max Reitz <mreitz@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org,
qemu-stable@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] block/vdi: Add locking for parallel requests
Date: Fri, 27 Feb 2015 18:34:58 +0100 [thread overview]
Message-ID: <54F0AAC2.6020202@weilnetz.de> (raw)
In-Reply-To: <54F0A957.5090906@redhat.com>
Am 27.02.2015 um 18:28 schrieb Max Reitz:
> On 2015-02-27 at 12:25, Stefan Weil wrote:
>> block/vdi.c was never written for multi-threaded access, see my comment
>> in the header of block/vdi.c:
>>
>> * The code is not thread safe (missing locks for changes in header and
>> * block table, no problem with current QEMU).
>>
>> This was true in the past, but obviously later multi-threaded access was
>> introduced for QEMU. Locking was added for qcow2 and other drivers in
>> 2012 and 2013, but never for vdi.
>>
>> I must admit that I don't know which parts of the block filesystem
>> drivers potentially run in parallel threads.Ideally there would be one
>> or more test cases which test multi-threaded operations and which
>> trigger a failure with the current vdi code.
>>
>> If I had a simple test scenario, I could have a look on the problem.
>
> I have one for you. See the attached ruby script.
>
> (If there are no "Pattern verification failed" messages, everything is
> good)
>
>> The VMDK approach is fine as an intermediate work around, but please use
>> conditional compilation to allow easy tests without coarse locks (and
>> update the comments :-)).
>
> Will a macro defined in vdi.c be enough?
Yes, that would be fine. vdi.c already has several locally defined
CONFIG_VDI_... macros.
Stefan
next prev parent reply other threads:[~2015-02-27 17:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-27 14:05 [Qemu-devel] [PATCH v2] block/vdi: Add locking for parallel requests Max Reitz
2015-02-27 16:57 ` Stefan Hajnoczi
2015-02-27 16:57 ` Max Reitz
2015-02-27 17:25 ` Stefan Weil
2015-02-27 17:28 ` Max Reitz
2015-02-27 17:34 ` Stefan Weil [this message]
2015-02-27 18:07 ` Stefan Weil
2015-02-27 18:09 ` Max Reitz
2015-02-27 18:12 ` Stefan Weil
2015-02-27 18:15 ` Max Reitz
2015-02-27 18:55 ` Max Reitz
2015-02-27 20:21 ` Stefan Weil
2015-02-27 20:23 ` Max Reitz
2015-02-27 20:37 ` Stefan Weil
2015-02-27 17:35 ` Paolo Bonzini
2015-02-27 17:42 ` Paolo Bonzini
2015-02-27 18:09 ` Max Reitz
2015-02-27 18:27 ` Max Reitz
2015-02-27 21:44 ` Stefan Weil
2015-02-27 21:46 ` Max Reitz
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=54F0AAC2.6020202@weilnetz.de \
--to=sw@weilnetz.de \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=stefanha@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.