On Tue, Jan 25, 2022 at 08:26:20AM +0100, Christian König wrote:
Hi Greg,
Am 24.01.22 um 19:41 schrieb Greg Kroah-Hartman:
From: Rajneesh Bhardwaj rajneesh.bhardwaj@amd.com
[ Upstream commit fbcdbfde87509d523132b59f661a355c731139d0 ]
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 Signed-off-by: Sasha Levin sashal@kernel.org
Please drop this patch from all stable versions since it was reverted from upstream later on.
The revert comes later in the patch series, so all should be ok :)
thanks,
greg k-h