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
