Now that IOASID core keeps track of the IOASID to mm_struct ownership in the forms of ioasid_set with IOASID_SET_TYPE_MM token type, there is no need to keep the same mapping in VT-d driver specific data. Native SVM usage is not affected by the change. Signed-off-by: Jacob Pan <jacob.jun.pan@xxxxxxxxxxxxxxx> --- drivers/iommu/intel/svm.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c index 2e764e283469..39a09a93300e 100644 --- a/drivers/iommu/intel/svm.c +++ b/drivers/iommu/intel/svm.c @@ -338,12 +338,6 @@ int intel_svm_bind_gpasid(struct iommu_domain *domain, struct device *dev, ret = -ENOMEM; goto out; } - /* REVISIT: upper layer/VFIO can track host process that bind - * the PASID. ioasid_set = mm might be sufficient for vfio to - * check pasid VMM ownership. We can drop the following line - * once VFIO and IOASID set check is in place. - */ - svm->mm = get_task_mm(current); svm->pasid = data->hpasid; if (data->flags & IOMMU_SVA_GPASID_VAL) { svm->gpasid = data->gpasid; @@ -351,7 +345,6 @@ int intel_svm_bind_gpasid(struct iommu_domain *domain, struct device *dev, } ioasid_attach_data(data->hpasid, svm); INIT_LIST_HEAD_RCU(&svm->devs); - mmput(svm->mm); } sdev = kzalloc(sizeof(*sdev), GFP_KERNEL); if (!sdev) { -- 2.7.4