Re: [Qemu-devel] qemu <-> libvirt communication regressed in QEMU commit 5243722376

[Paolo Bonzini <pbonzini@redhat.com>]

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
> <http://thread.gmane.org/gmane.comp.emulators.qemu/356765/focus=360602>.
> Was that concern cleared up eventually?

No, the patch was included by mistake.  Sorry.

Paolo