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(a)redhat.com>
---
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