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 >> <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.
NP, thanks for the quick action. Laszlo
