[PATCH] drm/ttm: Don't inherit GEM object VMAs in child process

Christian König ckoenig.leichtzumerken at gmail.com
Thu Dec 9 07:54:14 UTC 2021


Am 08.12.21 um 21:53 schrieb Rajneesh Bhardwaj:
> When an application having open file access to a node forks, its shared
> mappings also get reflected in the address space of child process even
> though it cannot access them with the object permissions applied. With the
> existing permission checks on the gem objects, it might be reasonable to
> also create the VMAs with VM_DONTCOPY flag so a user space application
> doesn't need to explicitly call the madvise(addr, len, MADV_DONTFORK)
> system call to prevent the pages in the mapped range to appear in the
> address space of the child process. It also prevents the memory leaks
> due to additional reference counts on the mapped BOs in the child
> process that prevented freeing the memory in the parent for which we had
> worked around earlier in the user space inside the thunk library.
>
> Additionally, we faced this issue when using CRIU to checkpoint restore
> an application that had such inherited mappings in the child which
> confuse CRIU when it mmaps on restore. Having this flag set for the
> render node VMAs helps. VMAs mapped via KFD already take care of this so
> this is needed only for the render nodes.

Unfortunately that is most likely a NAK. We already tried something similar.

While it is illegal by the OpenGL specification and doesn't work for 
most userspace stacks, we do have some implementations which call fork() 
with a GL context open and expect it to work.

Regards,
Christian.

>
> Cc: Felix Kuehling <Felix.Kuehling at amd.com>
>
> Signed-off-by: David Yat Sin <david.yatsin at amd.com>
> Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj at amd.com>
> ---
>   drivers/gpu/drm/drm_gem.c       | 3 ++-
>   drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +-
>   2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 09c820045859..d9c4149f36dd 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -1058,7 +1058,8 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size,
>   			goto err_drm_gem_object_put;
>   		}
>   
> -		vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
> +		vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND
> +				| VM_DONTDUMP | VM_DONTCOPY;
>   		vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
>   		vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
>   	}
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 33680c94127c..420a4898fdd2 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -566,7 +566,7 @@ int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct ttm_buffer_object *bo)
>   
>   	vma->vm_private_data = bo;
>   
> -	vma->vm_flags |= VM_PFNMAP;
> +	vma->vm_flags |= VM_PFNMAP | VM_DONTCOPY;
>   	vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
>   	return 0;
>   }



More information about the amd-gfx mailing list