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@xxxxxxxxxx>
> ---
> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
