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(a)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 :|