From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUSNA-00018T-Fe for qemu-devel@nongnu.org; Wed, 17 Sep 2014 23:27:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUSN4-0008KL-8K for qemu-devel@nongnu.org; Wed, 17 Sep 2014 23:27:08 -0400 Received: from mail-pd0-f169.google.com ([209.85.192.169]:44604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUSN4-0008Jc-2V for qemu-devel@nongnu.org; Wed, 17 Sep 2014 23:27:02 -0400 Received: by mail-pd0-f169.google.com with SMTP id fp1so460636pdb.28 for ; Wed, 17 Sep 2014 20:26:56 -0700 (PDT) Message-ID: <541A50F6.4060703@ozlabs.ru> Date: Thu, 18 Sep 2014 13:26:46 +1000 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <5416C46D.7040105@ozlabs.ru> <541826CA.7050607@ozlabs.ru> <541828BF.8090301@redhat.com> <20140917090615.GB10699@stefanha-thinkpad.redhat.com> <54195395.9010201@redhat.com> <5419902B.1030309@ozlabs.ru> In-Reply-To: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] migration: qemu-coroutine-lock.c:141: qemu_co_mutex_unlock: Assertion `mutex->locked == 1' failed List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , "qemu-devel@nongnu.org" , "Dr. David Alan Gilbert" , Stefan Hajnoczi , Paolo Bonzini , Max Reitz On 09/18/2014 01:07 AM, Stefan Hajnoczi wrote: > On Wed, Sep 17, 2014 at 2:44 PM, Alexey Kardashevskiy 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? -- Alexey