Remove the locks since they are unnecessary and would cause
a hang for a driver reload/restart when a transient pool was
previously active as a result of the call:
virStoragePoolUpdateInactive:
...
if (!virStoragePoolObjGetConfigFile(obj)) {
virStoragePoolObjRemove(driver->pools, obj);
...
stack trace:
Thread 17 (Thread 0x7fffcc574700 (LWP 12465)):
...pthread_rwlock_wrlock
...virRWLockWrite
...virObjectRWLockWrite
...virStoragePoolObjRemove
...virStoragePoolUpdateInactive
...storagePoolUpdateStateCallback
...virStoragePoolObjListForEachCb
...virHashForEach
...virStoragePoolObjListForEach
...storagePoolUpdateAllState
...storageStateInitialize
...virStateInitialize
...daemonRunStateInit
...virThreadHelper
...start_thread
...clone
Introduced by commit id
4b2e0ed6e3.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
* not as it's being used for Autostart and UpdateAllState callers
* that want to iterate over all the @pools objects not stopping if
* one happens to fail.
+ *
+ * NB: We cannot take the Storage Pool lock here because it's possible
+ * that some action as part of Autostart or UpdateAllState will need
+ * to modify/destroy a transient pool. Since these paths only occur
+ * during periods in which the storageDriverLock is held (Initialization,
+ * AutoStart, or Reload) this is OK.
*/
void
virStoragePoolObjListForEach(virStoragePoolObjListPtr pools,
struct _virStoragePoolObjListForEachData data = { .iter = iter,
.opaque = opaque };
- virObjectRWLockRead(pools);
virHashForEach(pools->objs, virStoragePoolObjListForEachCb, &data);
- virObjectRWUnlock(pools);
}