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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
