On Mon, Feb 11, 2013 at 02:02:21PM +0000, Richard W.M. Jones wrote:
This seems to be some sort of deadlock, easily reproduced by running
the libguestfs test suite, or even just 'libguestfs-test-tool'.
Here is a stack trace:
(gdb) t a a bt
Thread 8 (Thread 0x7fe64edd4700 (LWP 20024)):
#0 __lll_lock_wait ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
---Type <return> to continue, or q <return> to quit---
#1 0x000000328ca09ca6 in _L_lock_836 () from /lib64/libpthread.so.0
#2 0x000000328ca09ba8 in __GI___pthread_mutex_lock (
mutex=mutex@entry=0x7fe64006eb30) at pthread_mutex_lock.c:64
#3 0x00007fe650ad142d in virMutexLock (m=m@entry=0x7fe64006eb30)
at util/virthreadpthread.c:85
#4 0x00007fe650ac38de in virObjectLock (anyobj=anyobj@entry=0x7fe64006eb20)
at util/virobject.c:322
#5 0x00007fe650ce65b1 in virSecurityManagerGetModel (
mgr=mgr@entry=0x7fe64006eb20) at security/security_manager.c:236
#6 0x00007fe650ce994c in virSecuritySELinuxSecurityVerify (
mgr=0x7fe64006eb20, def=<optimized out>)
at security/security_selinux.c:1806
#7 0x00007fe650ce7251 in virSecurityManagerVerify (mgr=0x7fe64006eb20,
def=def@entry=0x7fe63400ac20) at security/security_manager.c:573
#8 0x00007fe650ce3cd4 in virSecurityStackVerify (mgr=<optimized out>,
def=0x7fe63400ac20) at security/security_stack.c:125
#9 0x00007fe650ce7251 in virSecurityManagerVerify (mgr=0x7fe64001cc50,
def=def@entry=0x7fe63400ac20) at security/security_manager.c:573
This shows the problem - the security driver implementations are not
allowed to call back out to other virSecurityManagerXXX APis like
virSecurityManagerGetModel, since that causes recursive mutex acquisition.
I've cc'd you on a fix
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 :|