On 02/21/2017 01:11 PM, Marc Hartmayer wrote: > The functions in virCommand() after fork() must be careful with regard > to accessing any mutexes that may have been locked by other threads in > the parent process. It is possible that another thread in the parent > process holds the lock for the virQEMUDriver while fork() is called. > This leads to a deadlock in the child process when > 'virQEMUDriverGetConfig(driver)' is called and therefore the handshake > never completes between the child and the parent process. Ultimately > the virDomainObjectPtr will never be unlocked. > > It gets much worse if the other thread of the parent process, that > holds the lock for the virQEMUDriver, tries to lock the already locked > virDomainObject. This leads to a completely unresponsive libvirtd. > > It's possible to reproduce this case with calling 'virsh start XXX' > and 'virsh managedsave XXX' in a tight loop for multiple domains. > > This commit fixes the deadlock in the same way as it is described in > commit 61b52d2e3813cc8c9ff3ab67f232bd0c65f7318d. > > Signed-off-by: Marc Hartmayer <mhartmay@xxxxxxxxxxxxxxxxxx> > Reviewed-by: Boris Fiuczynski <fiuczy@xxxxxxxxxxxxxxxxxx> > --- > src/qemu/qemu_domain.c | 73 +++++++++++++++++++++++-------------------------- > src/qemu/qemu_domain.h | 3 +- > src/qemu/qemu_process.c | 2 +- > 3 files changed, 37 insertions(+), 41 deletions(-) ACKed and pushed. Nice catch. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
