qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Laszlo Ersek
Subject: Re: [Qemu-devel] qemu <-> libvirt communication regressed in QEMU commit 5243722376
Date: Wed, 16 Sep 2015 15:16:44 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]