Re: [Qemu-devel] migration: qemu-coroutine-lock.c:141: qemu_co_mutex_unlock: Assertion `mutex->locked == 1' failed

[Paolo Bonzini <pbonzini@redhat.com>]

Il 18/09/2014 05:26, Alexey Kardashevskiy ha scritto:
> On 09/18/2014 01:07 AM, Stefan Hajnoczi wrote:
>> On Wed, Sep 17, 2014 at 2:44 PM, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>> On 09/17/2014 07:25 PM, Paolo Bonzini wrote:
>>> btw any better idea of a hack to try? Testers are pushing me - they want to
>>> upgrade the broken setup and I am blocking them :) Thanks!
>>
>> Paolo's qemu_co_mutex_lock(&s->lock) idea in qcow2_invalidate_cache()
>> is good.  Have you tried that patch?
> 
> 
> Yes, did not help.
> 
>>
>> I haven't checked the qcow2 code whether that works properly across
>> bdrv_close() (is the lock freed?) but in principle that's how you
>> protect against concurrent I/O.
> 
> I thought we have to avoid qemu_coroutine_yield() in this particular case.
> I fail to see how the locks may help if we still do yeild. But the whole
> thing is already way behind of my understanding :) For example - how many
> BlockDriverState things are layered here? NBD -> QCOW2 -> RAW?

No, this is an NBD server.  So we have three users of the same QCOW2
image: migration, NBD server and virtio disk (not active while the bug
happens, and thus not depicted):


              NBD server   ->    QCOW2     <-     migration
                                   |
                                   v
                                 File

The problem is that the NBD server accesses the QCOW2 image while
migration does qcow2_invalidate_cache.

Paolo