[libvirt] [PATCH v2 13/14] nodedev: Pass @def by reference to create/assign object

John Ferlan jferlan at redhat.com
Fri May 26 13:19:41 UTC 2017



On 05/26/2017 08:12 AM, Peter Krempa wrote:
> On Thu, May 25, 2017 at 15:57:10 -0400, John Ferlan wrote:
>> Since the @def is consumed by the assignment function, let's pass by
>> reference instead of value and really consume it.
>>
>> Signed-off-by: John Ferlan <jferlan at redhat.com>
>> ---
>>  src/conf/virnodedeviceobj.c        | 8 ++++----
>>  src/conf/virnodedeviceobj.h        | 2 +-
>>  src/node_device/node_device_hal.c  | 2 +-
>>  src/node_device/node_device_udev.c | 8 +++-----
>>  src/test/test_driver.c             | 5 ++---
>>  5 files changed, 11 insertions(+), 14 deletions(-)
>>
>> diff --git a/src/conf/virnodedeviceobj.c b/src/conf/virnodedeviceobj.c
>> index a7e51ef..1648b33 100644
>> --- a/src/conf/virnodedeviceobj.c
>> +++ b/src/conf/virnodedeviceobj.c
>> @@ -268,13 +268,13 @@ virNodeDeviceObjListFree(virNodeDeviceObjListPtr devs)
>>  
>>  virNodeDeviceObjPtr
>>  virNodeDeviceObjAssignDef(virNodeDeviceObjListPtr devs,
>> -                          virNodeDeviceDefPtr def)
>> +                          virNodeDeviceDefPtr *def)
> 
> I don't really like this. You can documment that this function either
> consumes def always or only on success and the callers can free the
> pointer. Passing the pointer to a pointer just to clear it in some cases
> is overcomplicating stuff.
> 

True, but I ran into in one case (I forget which one now) where the
assumption was that the @def wasn't consumed on a failure, but in
reality it had been.  The obj->def got assigned, then the attempt was
made to add the obj to the list which if it failed would call whatever
cleanup routine was there which free'd @obj->def and returned to the
caller with a failure which would attempt to free @def (again). My first
instinct was to just set obj->def = NULL prior to the cleanup, which
worked for a short time until obj->def was a "real" object and the
cleanup code didn't own obj any more.

So it's the long winded way of saying - I can drop this and the
following patch either be "more careful" as necessary or just claim at
some point in time that @def would be consumed on both success and
failure, which I think follows how virJSONValueObjectCreate eats the
"a:" arguments (and causes many false positives for Coverity).

John




More information about the libvir-list mailing list