drm/amdgpu: Don't inherit GEM object VMAs in child process
authorRajneesh Bhardwaj <rajneesh.bhardwaj@amd.com>
Fri, 26 Nov 2021 20:15:04 +0000 (15:15 -0500)
committerAlex Deucher <alexander.deucher@amd.com>
Tue, 28 Dec 2021 21:03:08 +0000 (16:03 -0500)
commitfbcdbfde87509d523132b59f661a355c731139d0
tree5b7051e8f7c2d311b956c4e09d60ac02b8dc0ff3
parentb6485bed40d7859735bdbfedbd55dcc8366a88a7
drm/amdgpu: Don't inherit GEM object VMAs in child process

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.

To limit the impact of the change to user space consumers such as OpenGL
etc, limit it to KFD BOs only.

Acked-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: David Yat Sin <david.yatsin@amd.com>
Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c