[libvirt] [PATCH 3/6] use virObject to manage reference-count of virDomainObj

Wen Congyang wency at cn.fujitsu.com
Tue Apr 12 10:22:12 UTC 2011


At 04/12/2011 01:51 PM, Hu Tao Write:
> Sorry, I unexpectedly deleted text body.
> 
> I changed the code like this:
> 
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index c2a1f9a..8aad0b3 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -514,7 +514,10 @@ int qemuDomainObjBeginJobWithDriver(struct qemud_driver *driver,
>              else
>                  virReportSystemError(errno,
>                                       "%s", _("cannot acquire job mutex"));
> +            virDomainObjUnlock(obj);
>              qemuDriverLock(driver);
> +            virDomainObjLock(obj);

We lock qemu_driver and vm as the folling steps:
1. lock qemu_driver
2. lock vm

We try to lock qemu_driver while holding the vm's lock.
OOps, it will cause the libvirtd deadlock.(I can reproduce this bug by your script)

> +            virDomainObjUnref(obj);

We have unref it, so do not unref it again.

>              return -1;
>          }
>      }
> 
> but still have problem. (see log in previous mail.) The reference count
> of virDomainObj becomes 0 while there are still threads accessing it.
> This causes two results: one is segmentation fault as shown in the log;
> the other is the qemu monitor fd is closed two early, and threads are
> polling a closed fd.
> 
> Steps of my test:
> 
>   1. change the value of max_clients in /etc/libvirt/libvirtd.conf to
>      big enough value:
>      
>      max_clients = 2000000
> 
>   2. run libvirtd
> 
>   3. run libvirt-test.sh hut-vm1 (hut-vm1 is my vm name) (warning: this
>      script forks many processes you have to kill by hand)
> 
> (again, the log and script libvirt-test.sh are in my previous mail)
> 
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
> 




More information about the libvir-list mailing list