Re: [PATCH kernel v4 3/4] vfio/spapr: Reference mm in tce_container
From: Nicholas Piggin <npiggin@gmail.com>
Date: 2016-10-24 07:14:35
On Mon, 24 Oct 2016 17:53:09 +1100 Alexey Kardashevskiy [off-list ref] wrote:
In some situations the userspace memory context may live longer than the userspace process itself so if we need to do proper memory context cleanup, we better have tce_container take a reference to mm_struct and use it later when the process is gone (@current or @current->mm is NULL). This references mm and stores the pointer in the container; this is done when a container is just created so checking for !current->mm in other places becomes pointless. This replaces current->mm with container->mm everywhere except debug prints. This adds a check that current->mm is the same as the one stored in the container to prevent userspace from making changes to a memory context of other processes; in order to add this check, VFIO_CHECK_EXTENSION is moved out of the switch(cmd) as it is quite special anyway - it is the only ioctl() called when neither container nor container->mm is initialized. Signed-off-by: Alexey Kardashevskiy <redacted> --- Changes: v4: * added check for container->mm!=current->mm in tce_iommu_ioctl() for all ioctls and removed other redundand checks
[...]
quoted hunk ↗ jump to hunk
@@ -326,13 +314,18 @@ static void *tce_iommu_open(unsigned long arg) container->v2 = arg == VFIO_SPAPR_TCE_v2_IOMMU; + /* current->mm cannot be NULL in this context */ + container->mm = current->mm; + atomic_inc(&container->mm->mm_count);
[...]
quoted hunk ↗ jump to hunk
@@ -733,7 +728,13 @@ static long tce_iommu_ioctl(void *iommu_data, } return (ret < 0) ? 0 : ret; + } + /* tce_iommu_open() initializes container->mm so it can't be NULL here */ + if (container->mm != current->mm) + return -ESRCH; + + switch (cmd) { case VFIO_IOMMU_SPAPR_TCE_GET_INFO: { struct vfio_iommu_spapr_tce_info info; struct tce_iommu_group *tcegrp;
I think doing the mm checks like this is a great improvement. Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Thanks, Nick