From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36022) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcBnX-0001Mw-KM for qemu-devel@nongnu.org; Wed, 16 Sep 2015 08:26:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZcBnU-0004GV-DK for qemu-devel@nongnu.org; Wed, 16 Sep 2015 08:26:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38943) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcBnU-0004GI-86 for qemu-devel@nongnu.org; Wed, 16 Sep 2015 08:26:48 -0400 References: <55F95CF2.3000401@redhat.com> From: Paolo Bonzini Message-ID: <55F96003.7030707@redhat.com> Date: Wed, 16 Sep 2015 14:26:43 +0200 MIME-Version: 1.0 In-Reply-To: <55F95CF2.3000401@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: Laszlo Ersek , "Emilio G. Cota" Cc: =?UTF-8?Q?Alex_Benn=c3=a9e?= , qemu devel list , Cole Robinson 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. Paolo