On Tue, Jun 07, 2022 at 07:44:37AM +0200, Christoph Hellwig wrote:
On Mon, Jun 06, 2022 at 09:34:36PM -0300, Jason Gunthorpe wrote:
if (!list_empty(&iommu->device_list)) {mutex_lock(&iommu->device_list_lock);mutex_unlock(&iommu->lock);list_for_each_entry(device,&iommu->device_list,iommu_entry)device->ops->dma_unmap(device, dma->iova, dma->size);mutex_unlock(&iommu->device_list_lock);mutex_lock(&iommu->lock);}I wonder if factoring this into a little helper instead of the very deep indentation might be a bit better for readability.
+static void vfio_iommu_type1_register_device(void *iommu_data,
struct vfio_device *vdev){ struct vfio_iommu *iommu = iommu_data;
if (!vdev->ops->dma_unmap)
return;mutex_lock(&iommu->lock);
mutex_lock(&iommu->device_list_lock);
list_add(&vdev->iommu_entry, &iommu->device_list);
mutex_unlock(&iommu->device_list_lock);
mutex_unlock(&iommu->lock);
Why do we need both iommu->lock and the device_list_lock everywhere?
Not everwhere, all the readers are using only one of the locks. The list empty calls that were previously unlocked are done under the iommu->lock and only the list iteration was done under the device_list.
Maybe explain the locking scheme somewhere so that people don't have to guess, because it seems to me that just using iommu->lock would be enough right now.
The expectation is that the dma_umap callback will re-enter the type1 driver via vfio_unpin_pages calls and this will recurse back onto the iommu->lock - so it must be dropped before invoking the callback.
I'll add a note
Jason