On Thu, Feb 28, 2013 at 01:33:31PM +0000, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange@redhat.com>
There is a lock ordering problem in the QEMU close callback APIs.
When starting a guest we have a lock on the VM. We then set a autodestroy callback, which acquires a lock on the close callbacks.
When running auto-destroy, we obtain a lock on the close callbacks, then run each callbacks - which obtains a lock on the VM.
This causes deadlock if anyone tries to start a VM, while autodestroy is taking place.
The fix is to do autodestroy in 2 phases. First obtain all the callbacks and remove them from the list under the close callback lock. Then invoke each callback from outside the close callback lock.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- src/qemu/qemu_conf.c | 106 ++++++++++++++++++++++++++++++++++++++++++-------- src/util/virnetlink.c | 5 ++- 2 files changed, 92 insertions(+), 19 deletions(-)
Incidentally this patch is also a huge performance win. Previously once autodestroy starts running it blocks all startup/shutdown of VMs. When a single client had created 1000 VMs, this blocked libvirtd for a very long time indeed. With this change we get full parallelism in auto-destroy since only 1 VM at a time is locked, and other VMs can continue to start/stop Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|