The locks we have seen are not the same (not both blocking on the same lock). One is on the FDST (virObjLock) And the other is on devs->lock of the virChrdevs priv->devs->lock == fdst->icbOpaque->devs->lock, the assumption is that this is already held by the path undefine takes
Analyzing the backtraces I found crossover locking triggering the deadlock: I'll call the stack of undefine "U" and the stack of daemonStreamHandleAbort "A": 1A: already has FDST locked in virFDStreamCloseInt 2A: calls virChrdevFDStreamCloseCb which blocks on locks priv->devs->lock 3U: virFDStreamSetInternalCloseCb blocks on locking FDST 4U: virChrdevFree -> ... -> virFDStreamSetInternalCloseCb 5U: virChrdevFree does virMutexLock(&devs->lock); So it seems that: - 5U (holds) and 2A (blocks) collide on devs->lock - 1A (holds) and 3U (blocks) collide on virObjectLock(fdst) Seems like a classic entangled deadlock :-/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1822096 Title: libvirt hangs after utah workload is aborted To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1822096/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
