From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51567) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcCZt-00084z-Co for qemu-devel@nongnu.org; Wed, 16 Sep 2015 09:16:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZcCZs-0001GZ-20 for qemu-devel@nongnu.org; Wed, 16 Sep 2015 09:16:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcCZr-0001GV-Sj for qemu-devel@nongnu.org; Wed, 16 Sep 2015 09:16:47 -0400 References: <55F95CF2.3000401@redhat.com> <55F96003.7030707@redhat.com> From: Laszlo Ersek Message-ID: <55F96BBC.80709@redhat.com> Date: Wed, 16 Sep 2015 15:16:44 +0200 MIME-Version: 1.0 In-Reply-To: <55F96003.7030707@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qemu <-> libvirt communication regressed in QEMU commit 5243722376 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , "Emilio G. Cota" Cc: =?UTF-8?Q?Alex_Benn=c3=a9e?= , qemu devel list , Cole Robinson On 09/16/15 14:26, Paolo Bonzini wrote: > > > On 16/09/2015 14:13, Laszlo Ersek wrote: >> >> Your patch causes "rcu_registry_lock" to be reinitialized in the child, >> rather than released, plus "rcu_sync_lock" remains untouched (ie. locked >> by the one thread that exists in the child). Why is that correct? >> >> (Side note: we're talking process-private, not process-shared mutexen.) >> >> I can be easily wrong, but I don't understand the commit message, and >> why the patch is correct. >> >> ... Hm, I can see the discussion here: >> >> http://thread.gmane.org/gmane.comp.emulators.qemu/356765/focus=360421 >> >> Okay... let me see 24fa90499f... "The problem is that releasing >> error-checking locks in the child fails under glibc with EPERM". <-- >> That is a striking surprise to me, but still, the removal of >> PTHREAD_MUTEX_ERRORCHECK only justifies why your patch would *not* be >> necessary. >> >> The last paragraph of your email that I linked above talks about a >> "possibility of corruption". Maybe I've managed to trigger that. If so, >> I hope it won't be hard to fix up. >> >> ... Hm, apparently Alex had mentioned the same concern as I did now, >> about ignoring "rcu_sync_lock" in the child, in message >> . >> Was that concern cleared up eventually? > > No, the patch was included by mistake. Sorry. NP, thanks for the quick action. Laszlo