On 08/01/2017 02:05 AM, John Ferlan wrote:
Now that virObjectRWLockWrite exists to handle the
virObjectRWLockable
objects, let's restore virObjectLock to only handle virObjectLockable
class locks. There still exists the possibility that the input @anyobj
isn't a valid object and the resource isn't truly locked, but that
also exists before commit id '77f4593b'.
This also restores some logic that commit id '77f4593b' removed
with respect to a common code path that commit id '10c2bb2b' had
introduced as virObjectGetLockableObj. This code path merely does
the same checks as the original virObjectLock commit 'b545f65d',
but in callable/reusable helper to ensure the @obj at least has
some validity before using.
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
src/util/virobject.c | 37 +++++++++++++++++++++++--------------
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/src/util/virobject.c b/src/util/virobject.c
index f49af62..4903393 100644
--- a/src/util/virobject.c
+++ b/src/util/virobject.c
@@ -367,13 +367,28 @@ virObjectRef(void *anyobj)
}
+static virObjectLockablePtr
+virObjectGetLockableObj(void *anyobj)
+{
+ virObjectPtr obj;
+
+ if (virObjectIsClass(anyobj, virObjectLockableClass))
+ return anyobj;
+
+ obj = anyobj;
+ VIR_WARN("Object %p (%s) is not a virObjectLockable instance",
+ anyobj, obj ? obj->klass->name : "(unknown)");
If we're really worried about this (and don't want to abort()), we might
consider raising this to VIR_ERROR. I'm a programmer, I don't care about
warnings O:-)
Michal