For a disk backend, the deleteVol code will clear all the volumes in the pool and perform a pool refresh, thus the storageVolDeleteInternal should not use access @voldef after deleteVol succeeds. Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> --- src/storage/storage_driver.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index f590f6b9b..3b66d5171 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -1670,15 +1670,21 @@ storageVolDeleteInternal(virStorageVolPtr vol, if (backend->deleteVol(vol->conn, obj, voldef, flags) < 0) goto cleanup; + /* The disk backend updated the pool data including removing the + * voldef from the pool (for both the deleteVol and the createVol + * failure path. */ + if (def->type == VIR_STORAGE_POOL_DISK) { + ret = 0; + goto cleanup; + } + /* Update pool metadata - don't update meta data from error paths * in this module since the allocation/available weren't adjusted yet. * Ignore the disk backend since it updates the pool values. */ if (updateMeta) { - if (def->type != VIR_STORAGE_POOL_DISK) { - def->allocation -= voldef->target.allocation; - def->available += voldef->target.allocation; - } + def->allocation -= voldef->target.allocation; + def->available += voldef->target.allocation; } virStoragePoolObjRemoveVol(obj, voldef); -- 2.13.6 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list