From c53e4ae0c83d4e1962b63de413f229af77ff57cc Mon Sep 17 00:00:00 2001 From: John Ferlan Date: Feb 26 2016 12:23:05 +0000 Subject: storage: Fix error path in virStoragePoolObjLoad While reviewing how storage driver used ObjListPtr's for reference in some recent secret driver patches to use the same mechanism, I came across an instance where the wrong API was called for error paths after successfully allocating the storage pool pointer and inserting into the driver pool list. The path is after virStoragePoolObjAssignDef succeeds - the 'def' passed in is assigned to pool->def (or newDef) so it shouldn't be the only thing deleted. The pool is now part of driver->pools.objs, so it would need to be removed (as happens in the storagePoolCreateXML error paths). Rather than calling virStoragePoolDefFree to free the def which is now assigned to the pool, call virStoragePoolObjRemove to ensure the pool element is removed from the driver list and that anything stored in pool is properly handled by virStoragePoolObjFree including the call to virStoragePoolDefFree for the pool->{def|newDef} element. --- diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c index 3657dfd..bfba521 100644 --- a/src/conf/storage_conf.c +++ b/src/conf/storage_conf.c @@ -1852,12 +1852,12 @@ virStoragePoolObjLoad(virStoragePoolObjListPtr pools, VIR_FREE(pool->configFile); /* for driver reload */ if (VIR_STRDUP(pool->configFile, path) < 0) { - virStoragePoolDefFree(def); + virStoragePoolObjRemove(pools, pool); return NULL; } VIR_FREE(pool->autostartLink); /* for driver reload */ if (VIR_STRDUP(pool->autostartLink, autostartLink) < 0) { - virStoragePoolDefFree(def); + virStoragePoolObjRemove(pools, pool); return NULL; }