As described recently on list:
https://www.redhat.com/archives/libvir-list/2017-November/msg00043.html
and then discussed more in depth recently on OFTC #virt IRC, the
thread run after a storageVolUpload is completed to refresh the volume
and pool statistics could cause a crash if there was a storageVolCreateXML
being run in a different thread that was taking a long time to build the
volume. In the create/build case, the storage pool is unlocked while the
build occurs, but before doing so "asyncjobs" is incremented to avoid
certain other destructive operations such as PoolUndefine, PoolDestroy,
PoolDelete, and PoolRefresh. The poolRefresh will clear and repopulate
the pool volume list which is a bad thing to do since the create logic
will have added to that list and be keeping track of what was added just
in case the volume would need to be removed in the event of a build
failure.
The patches here will fix the case found and then alter the logic for
another possible miscreant that would clear the volumes in a thread that
needs to be run "later" than the normal processing for SCSI Fibre Channel
volume recognition.
John Ferlan (2):
storage: Resolve storage driver crash
scsi: Check for long running create in FCRefreshThread
src/storage/storage_backend_scsi.c | 1 +
src/storage/storage_driver.c | 9 +++++++++
2 files changed, 10 insertions(+)
--
2.13.6