On 06/03/2017 03:27 PM, John Ferlan wrote: > Rather than rely on virSecretObjEndAPI to make the final virObjectUnref > after the call virSecretObjListRemove, be more explicit by calling > virObjectUnref and setting @obj to NULL for secretUndefine and in > the error path of secretDefineXML. > > This also fixes a leak during virSecretLoad if the virSecretLoadValue > fails the code jumps to cleanup without setting @ret = obj, thus calling > virSecretObjListRemove which only accounts for the object reference > related to adding the object to the list during virSecretObjListAdd, > but does not account for the reference to the object itself as the > return of @ret would be NULL so the caller wouldn't call virSecretObjEndAPI > on the object recently added thus reducing the refcnt to zero. Thus > cleaning up the virSecretLoadValue error path to make it clearer what > needs to be done on failure. I think the real reason is that we cannot call virSecretObjEndAPI() because that *unlocks* the secret object. However, the object is already unlocked at that point by virSecretObjListRemove() and thus we would unlock twice while locking just once. Honestly, I'd rather see that explanation in the commit message. But it's your call. > > Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> > --- > src/conf/virsecretobj.c | 14 ++++++-------- > src/secret/secret_driver.c | 9 +++++++-- > 2 files changed, 13 insertions(+), 10 deletions(-) ACK Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
