On 07.01.2014 18:42, Eric Blake wrote:
On 01/07/2014 10:25 AM, Michal Privoznik wrote:
The function checks for @conn to be valid and locks its mutex. Then, it checks if callee is unregistering the same callback that he registered previously. If this fails an error is reported and the control jumps to 'error' label. Here, if @conn has some errors (and it certainly does - the one that's been just reported) the conn->mutex is locked again - without any previous unlock:
ACK; bug introduced in commit ca0ea2a.
AHA! In that case this patch is incomplete as looking at the blamed commit I've found another candidate worth fixing (even though I have not experienced any deadlock in it yet): virConnectRegisterCloseCallback(). I've squashed this in prior to push: diff --git a/src/libvirt.c b/src/libvirt.c index 1f5590f..619da80 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -20446,9 +20446,9 @@ virConnectRegisterCloseCallback(virConnectPtr conn, return 0; error: - virDispatchError(conn); virObjectUnlock(conn->closeCallback); virMutexUnlock(&conn->lock); + virDispatchError(conn); virObjectUnref(conn); return -1; } Thanks! Michal