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@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list