[libvirt] [PATCH 11/14] xen: Resource resource leak with 'cpuset'

[Eric Blake]

On 01/09/2013 07:07 PM, Laine Stump wrote:
>>>
>> According to Coverity's analysis this may not be true since it's
>> "possible" to hit the "ret--" line (more than once) in virBitmapParse()
>> while hitting either "ret++" line less times returning a negative value
>> on the "success" path. The example Coverity had shows 6 passes through
>> the loop, 4 negatives, 1 positive, and 1 nothing.
>>
>> Whether realistically this could be true, I am not sure.
>>
>> How Coverity determined what the value of 'cpuSet' is a mystery as the
>> output I have doesn't show what's being used for parsing, just that we
>> go through the loop 6 times. Perhaps something like "^1,^2,^3,4,^5,^6"
>> where 1,2,3,4,5,6 pass the virBitmapIsSet() call changing the 'ret'
>> value to -3.

Except that we would have rejected '^1' outright up front.

> 
> I don't think that is possible. In order for virBitmapIsSet() to return
> true for a particular bit, that bit must be set, and in order for that
> bit to be set, it must have been set in a previous iteration of this
> same loop (remember that the bitmap is initialized to all empty at the
> top of the function), which means that ret++ must have been executed. So
> ret-- can't happen without a previous corresponding ret++, therefore the
> value of ret can't be < 0.

Maybe a well-placed:

sa_assert(ret >= 0);

will help Coverity learn a bit more of the logic flow, which proves that
we cannot reach the success path with too many ret-- lines.

> 
> If it was possible to have a return < 0 on success, that would be a bug
> in the function that would need to be fixed.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130109/49219efa/attachment-0001.sig>