On Fri, Mar 04, 2011 at 06:03:36PM -0700, Eric Blake wrote: > On 03/04/2011 02:46 PM, Eric Blake wrote: > >> +++ b/src/qemu/qemu_process.c > >> @@ -596,7 +596,9 @@ static void qemuProcessHandleMonitorDestroy(qemuMonitorPtr mon, > >> qemuDomainObjPrivatePtr priv = vm->privateData; > >> if (priv->mon == mon) > >> priv->mon = NULL; > >> - virDomainObjUnref(vm); > >> + virDomainObjLock(vm); > >> + if (virDomainObjUnref(vm) > 0) > >> + virDomainObjUnlock(vm); > > > > Phooey, this causes 'virsh save domain file' to deadlock. > > > > I'm still looking into why, but it may be that we're going about fixing > > this wrong. Maybe we should be making sure that qemuProcessStop ensures > > that the monitor callback function won't trigger if there is no domain > > for it to trigger on. > > I think the real reason for the deadlock is that: > > qemudDomainSaveFlag holds the domain lock while it calls > qemuDomainEventQueue, which requests the event loop lock > > the event loop thread holds the event loop lock, and can make several > different callbacks that can result in requesting a domain lock I don't think this can be the deadlock scenario. The event loop lock is completely isolated from other locks, because it is only ever held while code in event.c is executing. It is always released when invoking any external callbacks, so you can't have any lock ordering dependencies wrt the event loop lock. Regards, 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list