On 03/03/2011 02:10 PM, Laine Stump wrote:
(Eric pointed out in IRC that I should be acquiring the domainobj lock prior to modifying obj->privateData->mon)
The solution is to have qemuMonitorFree lock the domain object right before unrefing it. Since the caller to qemuMonitorFree doesn't expect this lock to be held, if the refcount doesn't go all the way to 0, qemuMonitorFree must unlock it after the unref. --- src/qemu/qemu_process.c | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index c419c75..9084725 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -593,10 +593,14 @@ no_memory: static void qemuProcessHandleMonitorDestroy(qemuMonitorPtr mon, virDomainObjPtr vm) { - qemuDomainObjPrivatePtr priv = vm->privateData; + qemuDomainObjPrivatePtr priv; + + virDomainObjLock(vm); + priv = vm->privateData; if (priv->mon == mon) priv->mon = NULL; - virDomainObjUnref(vm); + if (virDomainObjUnref(vm) > 0) + virDomainObjUnlock(vm); }
ACK from me for following the rules in src/qemu/THREADS.txt, although you may want to wait for danpb to weigh in. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org