From: Daniel P. Berrange berra...@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
On Thu, Feb 28, 2013 at 01:33:31PM +, Daniel P. Berrange wrote:
From: Daniel P. Berrange berra...@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
On Thu, Feb 28, 2013 at 13:33:31 +, Daniel P. Berrange wrote:
From: Daniel P. Berrange berra...@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
On Thu, Feb 28, 2013 at 02:50:34PM +0100, Jiri Denemark wrote:
On Thu, Feb 28, 2013 at 13:33:31 +, Daniel P. Berrange wrote:
From: Daniel P. Berrange berra...@redhat.com
There is a lock ordering problem in the QEMU close callback
APIs.
When starting a guest we have a lock on the
On Thu, Feb 28, 2013 at 01:33:31PM +, Daniel P. Berrange wrote:
From: Daniel P. Berrange berra...@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
On Thu, Feb 28, 2013 at 13:33:31 +, Daniel P. Berrange wrote:
From: Daniel P. Berrange berra...@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