On 2015-02-27 at 16:44, Stefan Weil wrote:
Am 27.02.2015 um 18:42 schrieb Paolo Bonzini:
An optimized fix could be to use a CoRwLock, then:
Note related to our previous discussion: why does the code use
CoRwlock instead of CoRwLock? Should it be renamed before more code
uses it?
Well, I'
Am 27.02.2015 um 18:42 schrieb Paolo Bonzini:
An optimized fix could be to use a CoRwLock, then:
Note related to our previous discussion: why does the code use CoRwlock
instead of CoRwLock? Should it be renamed before more code uses it?
Stefan
Am 27.02.2015 um 21:23 schrieb Max Reitz:
On 2015-02-27 at 15:21, Stefan Weil wrote:
Am 27.02.2015 um 19:55 schrieb Max Reitz:
On 2015-02-27 at 13:15, Max Reitz wrote:
On 2015-02-27 at 13:12, Stefan Weil wrote:
Am 27.02.2015 um 19:09 schrieb Max Reitz:
It always fails for me. Do you have an
Am 27.02.2015 um 19:55 schrieb Max Reitz:
On 2015-02-27 at 13:15, Max Reitz wrote:
On 2015-02-27 at 13:12, Stefan Weil wrote:
Am 27.02.2015 um 19:09 schrieb Max Reitz:
It always fails for me. Do you have an SSD?
On the real machine: yes. On the virtual machine: maybe.
I don't, so maybe that
On 2015-02-27 at 15:21, Stefan Weil wrote:
Am 27.02.2015 um 19:55 schrieb Max Reitz:
On 2015-02-27 at 13:15, Max Reitz wrote:
On 2015-02-27 at 13:12, Stefan Weil wrote:
Am 27.02.2015 um 19:09 schrieb Max Reitz:
It always fails for me. Do you have an SSD?
On the real machine: yes. On the virt
On 2015-02-27 at 13:15, Max Reitz wrote:
On 2015-02-27 at 13:12, Stefan Weil wrote:
Am 27.02.2015 um 19:09 schrieb Max Reitz:
It always fails for me. Do you have an SSD?
On the real machine: yes. On the virtual machine: maybe.
I don't, so maybe that's the issue. But running it in tmpfs doesn
On 2015-02-27 at 13:09, Max Reitz wrote:
On 2015-02-27 at 12:42, Paolo Bonzini wrote:
On 27/02/2015 15:05, Max Reitz wrote:
Concurrently modifying the bmap does not seem to be a good idea;
this patch adds
a lock for it. See https://bugs.launchpad.net/qemu/+bug/1422307 for
what
can go wrong w
On 2015-02-27 at 13:12, Stefan Weil wrote:
Am 27.02.2015 um 19:09 schrieb Max Reitz:
It always fails for me. Do you have an SSD?
On the real machine: yes. On the virtual machine: maybe.
I don't, so maybe that's the issue. But running it in tmpfs doesn't
change anything for me, still fails (e
Am 27.02.2015 um 19:09 schrieb Max Reitz:
> It always fails for me. Do you have an SSD?
On the real machine: yes. On the virtual machine: maybe.
On 2015-02-27 at 13:07, Stefan Weil wrote:
Am 27.02.2015 um 18:28 schrieb Max Reitz:
On 2015-02-27 at 12:25, Stefan Weil wrote:
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"
On 2015-02-27 at 12:42, Paolo Bonzini wrote:
On 27/02/2015 15:05, Max Reitz wrote:
Concurrently modifying the bmap does not seem to be a good idea; this patch adds
a lock for it. See https://bugs.launchpad.net/qemu/+bug/1422307 for what
can go wrong without.
Cc: qemu-stable
Signed-off-by: Max
Am 27.02.2015 um 18:28 schrieb Max Reitz:
> On 2015-02-27 at 12:25, Stefan Weil wrote:
>> 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)
Yo
On 27/02/2015 15:05, Max Reitz wrote:
> Concurrently modifying the bmap does not seem to be a good idea; this patch
> adds
> a lock for it. See https://bugs.launchpad.net/qemu/+bug/1422307 for what
> can go wrong without.
>
> Cc: qemu-stable
> Signed-off-by: Max Reitz
> ---
> v2:
> - Make the
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 pr
On 27/02/2015 18:25, Stefan Weil wrote:
> block/vdi.c was never written for multi-threaded access, see my comment
> in the header of block/vdi.c:
It is not using threads, only coroutines. Preemption points of
coroutines are well defined, and I think that the bug could be present
even in the ini
On 2015-02-27 at 12:25, Stefan Weil wrote:
Am 27.02.2015 um 17:57 schrieb Stefan Hajnoczi:
On Fri, Feb 27, 2015 at 09:05:47AM -0500, Max Reitz wrote:
Concurrently modifying the bmap does not seem to be a good idea; this patch adds
a lock for it. See https://bugs.launchpad.net/qemu/+bug/1422307
Am 27.02.2015 um 17:57 schrieb Stefan Hajnoczi:
> On Fri, Feb 27, 2015 at 09:05:47AM -0500, Max Reitz wrote:
>> Concurrently modifying the bmap does not seem to be a good idea; this patch
>> adds
>> a lock for it. See https://bugs.launchpad.net/qemu/+bug/1422307 for what
>> can go wrong without.
>
On 2015-02-27 at 11:57, Stefan Hajnoczi wrote:
On Fri, Feb 27, 2015 at 09:05:47AM -0500, Max Reitz wrote:
Concurrently modifying the bmap does not seem to be a good idea; this patch adds
a lock for it. See https://bugs.launchpad.net/qemu/+bug/1422307 for what
can go wrong without.
Cc: qemu-stab
On Fri, Feb 27, 2015 at 09:05:47AM -0500, Max Reitz wrote:
> Concurrently modifying the bmap does not seem to be a good idea; this patch
> adds
> a lock for it. See https://bugs.launchpad.net/qemu/+bug/1422307 for what
> can go wrong without.
>
> Cc: qemu-stable
> Signed-off-by: Max Reitz
> ---
Concurrently modifying the bmap does not seem to be a good idea; this patch adds
a lock for it. See https://bugs.launchpad.net/qemu/+bug/1422307 for what
can go wrong without.
Cc: qemu-stable
Signed-off-by: Max Reitz
---
v2:
- Make the mutex cover vdi_co_write() completely [Kevin]
- Add a TODO c
20 matches
Mail list logo
