| Message ID | 20220623115603.22288-1-lizhe.67@bytedance.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC] vfio: remove useless judgement | expand |
On Thu, Jun 23, 2022 at 07:56:03PM +0800, lizhe.67@bytedance.com wrote: > From: Li Zhe <lizhe.67@bytedance.com> > > In function vfio_dma_do_unmap(), we currently prevent process to unmap > vfio dma region whose mm_struct is different from the vfio_dma->task. > In our virtual machine scenario which is using kvm and qemu, this > judgement stops us from liveupgrading our qemu, which uses fork() && > exec() to load the new binary but the new process cannot do the > VFIO_IOMMU_UNMAP_DMA action during vm exit because of this judgement. > > This judgement is added in commit 8f0d5bb95f76 ("vfio iommu type1: Add > task structure to vfio_dma") for the security reason. But it seems that > no other task who has no family relationship with old and new process > can get the same vfio_dma struct here for the reason of resource > isolation. So this patch delete it. > > Signed-off-by: Li Zhe <lizhe.67@bytedance.com> > --- > drivers/vfio/vfio_iommu_type1.c | 6 ------ > 1 file changed, 6 deletions(-) I'm inclined to agree with this reasoning and deliberately did not include a similar check in iommufd. Any process with access to the container FD should be able to manipulate the IOVA space. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Jason
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c index c13b9290e357..a8ff00dad834 100644 --- a/drivers/vfio/vfio_iommu_type1.c +++ b/drivers/vfio/vfio_iommu_type1.c @@ -1377,12 +1377,6 @@ static int vfio_dma_do_unmap(struct vfio_iommu *iommu, if (!iommu->v2 && iova > dma->iova) break; - /* - * Task with same address space who mapped this iova range is - * allowed to unmap the iova range. - */ - if (dma->task->mm != current->mm) - break; if (invalidate_vaddr) { if (dma->vaddr_invalid) {