On 11.11.2016 16:32, Erik Skultety wrote:
The only place we change the @conn object is actually
virAdmConnectOpen
routine, thus at the moment we don't really need to lock it, given the fact that
what we're trying to do here is to change the closeCallback object which is a
lockable object itself, so that should be enough to avoid races.
Signed-off-by: Erik Skultety <eskultet(a)redhat.com>
---
src/libvirt-admin.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/src/libvirt-admin.c b/src/libvirt-admin.c
index 88eef54..1b5fd44 100644
--- a/src/libvirt-admin.c
+++ b/src/libvirt-admin.c
@@ -465,7 +465,6 @@ int virAdmConnectRegisterCloseCallback(virAdmConnectPtr conn,
virObjectRef(conn);
- virObjectLock(conn);
virObjectLock(conn->closeCallback);
virCheckNonNullArgGoto(cb, error);
@@ -482,13 +481,11 @@ int virAdmConnectRegisterCloseCallback(virAdmConnectPtr conn,
conn->closeCallback->freeCallback = freecb;
virObjectUnlock(conn->closeCallback);
- virObjectUnlock(conn);
Well, sometimes we are locking objects just for the sake of lock
ordering. But looking into the code I cannot find any other place where
they would rely on some specific lock ordering.
Michal