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(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org