[PATCH v2 10/13] qemu: avoid deadlock in qemuDomainObjStopWorker

[Daniel Henrique Barboza]

On 8/11/20 3:39 AM, Nikolay Shirokovskiy wrote:
> 
> 
> On 10.08.2020 20:40, Daniel Henrique Barboza wrote:
>>
>>
>> On 7/23/20 7:14 AM, Nikolay Shirokovskiy wrote:
>>> We are dropping the only reference here so that the event loop thread
>>> is going to be exited synchronously. In order to avoid deadlocks we
>>> need to unlock the VM so that any handler being called can finish
>>> execution and thus even loop thread be finished too.

>>
>>
>> Given that this code only makes sense when called from qemuDomainObjStopWorkerIter(),
>> I'd suggest removing the lock/unlock of this function (turning it into just a call
>> to qemuDomainObjStopWorker()) and move them inside the body of qemuDomainObjStopWorker(),
>> locking and unlocking the mutex inside the scope of the same function.
>>
> 
> Hi, Daniel.
> 
> Actually all callers of qemuProcessStop hold the lock. Moreover they even hold
> job condition. And calling qemuProcessStop without lock/job condition would be
> a mistake AFIU (qemuConnectDomainXMLToNative is the only exception I see that
> holds the lock but not the job condition. But this function creates new vm
> object that is not shared with other threads) I understand you concern but
> there are precedents. Take a look for example virDomainObjListRemove. The
> lock requirements are documented for virDomainObjListRemove and I can do it for
> qemuDomainObjStopWorker too but it looks a bit over documenting to me.


Got it. Thanks for explaining.



> 
> Nikolay
>