[libvirt] storage lock issues

Cedric Bosdonnat cbosdonnat at suse.com
Thu Nov 2 15:44:13 UTC 2017


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




More information about the libvir-list mailing list