On Thu, Feb 28, 2013 at 02:50:34PM +0100, Jiri Denemark wrote:
On Thu, Feb 28, 2013 at 13:33:31 +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.
Looks like we can just remove 568a6cda277f04ab9baaeb97490e548b7b608aa6 then, can't we?
Quite possibly. I'll investigate that further, and test what happens. 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 :|