Re: [libvirt] storage lock issues
On Thu, 2017-11-02 at 07:03 -0400, John Ferlan wrote:
So how to fix - well seems to me the storageDriverLock in
VolCreateXML
may be the way since the refresh thread takes the driver lock first,
then the pool object second. Perhaps even like the build code where it
takes it temporarily while getting the pool object. I'd have to think a
bit more about though. Still might be something to try since the Vol
Refresh thread takes it while running...
This is surely a bad hack, but this is fixing the problem I'm seeing.
Wouldn't the VolCreateXML function taking the lock for a too long time
and thus lead to other troubles?
---- %< ----
diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c
index 18d630319..f5a1e7bc2 100644
--- a/src/storage/storage_driver.c
+++ b/src/storage/storage_driver.c
@@ -1825,6 +1825,7 @@ storageVolCreateXML(virStoragePoolPtr obj,
if (backend->createVol(obj->conn, pool, voldef) < 0)
goto cleanup;
+ storageDriverLock();
pool->volumes.objs[pool->volumes.count++] = voldef;
volobj = virGetStorageVol(obj->conn, pool->def->name, voldef->name,
voldef->key, NULL, NULL);
@@ -1858,9 +1859,7 @@ storageVolCreateXML(virStoragePoolPtr obj,
VIR_FREE(buildvoldef);
- storageDriverLock();
virStoragePoolObjLock(pool);
- storageDriverUnlock();
voldef->building = false;
pool->asyncjobs--;
@@ -1897,6 +1896,7 @@ storageVolCreateXML(virStoragePoolPtr obj,
voldef = NULL;
cleanup:
+ storageDriverUnlock();
virObjectUnref(volobj);
virStorageVolDefFree(voldef);
if (pool)
---- %< ----
--
Cedric