Patch "drm/amdgpu: Don't inherit GEM object VMAs in child process" has been added to the 5.15-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    drm/amdgpu: Don't inherit GEM object VMAs in child process

to the 5.15-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     drm-amdgpu-don-t-inherit-gem-object-vmas-in-child-pr.patch
and it can be found in the queue-5.15 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 66a84f68a911b9865e0158ffe332a998aa377b73
Author: Rajneesh Bhardwaj <rajneesh.bhardwaj@xxxxxxx>
Date:   Fri Nov 26 15:15:04 2021 -0500

    drm/amdgpu: Don't inherit GEM object VMAs in child process
    
    [ 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@xxxxxxx>
    Reviewed-by: Christian König <christian.koenig@xxxxxxx>
    Signed-off-by: David Yat Sin <david.yatsin@xxxxxxx>
    Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@xxxxxxx>
    Signed-off-by: Alex Deucher <alexander.deucher@xxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index a1e63ba4c54a5..630dc99e49086 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -264,6 +264,9 @@ static int amdgpu_gem_object_mmap(struct drm_gem_object *obj, struct vm_area_str
 	    !(vma->vm_flags & (VM_READ | VM_WRITE | VM_EXEC)))
 		vma->vm_flags &= ~VM_MAYWRITE;
 
+	if (bo->kfd_bo)
+		vma->vm_flags |= VM_DONTCOPY;
+
 	return drm_gem_ttm_mmap(obj, vma);
 }
 



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux