[libvirt] [PATCH v2 3/8] util: Only have virObjectLock handle virObjectLockable

Michal Privoznik mprivozn at redhat.com
Thu Aug 3 15:38:33 UTC 2017


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 at 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




More information about the libvir-list mailing list