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

Re: [libvirt] [PATCH] Fix (rare) deadlock in QEMU monitor callbacks



On 09/26/2012 08:56 AM, Daniel P. Berrange wrote:
> From: "Daniel P. Berrange" <berrange redhat com>
> 
> Some users report (very rarely) seeing a deadlock in the QEMU
> monitor callbacks
> 
> Thread 10 (Thread 0x7fcd11e20700 (LWP 26753)):
>     at util/threads-pthread.c:85
>     at conf/domain_conf.c:14256
>     vm=0x7fcccc00a850) at qemu/qemu_process.c:1026
>     at qemu/qemu_monitor.c:249
>     at util/virobject.c:139
>     at qemu/qemu_monitor.c:860
>     vm=vm entry=0x7fcccc00a850,
>     reason=reason entry=VIR_DOMAIN_SHUTOFF_DESTROYED, flags=flags entry=0)
>     at qemu/qemu_process.c:4057
>     flags=<optimized out>) at qemu/qemu_driver.c:1977
>     domain=domain entry=0x7fccf00c1830, flags=1) at libvirt.c:2256
> 
> At frame #10 we are holding the domain lock, we call into
> qemuProcessStop() to cleanup QEMU, which triggers the monitor
> to close, which invokes qemuProcessHandleMonitorDestroy() which
> tries to obtain the domain lock again. This is a non-recursive
> lock, hence hang.
> 
> Since qemuMonitorPtr is a virObject, the unref call in
> qemuProcessHandleMonitorDestroy no longer needs mutex
> protection. The assignment of priv->mon = NULL, can be
> instead done by the caller of qemuMonitorClose(), thus
> removing all need for locking.

ACK.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


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