1. 22 11月, 2022 2 次提交
  2. 27 5月, 2022 2 次提交
  3. 07 4月, 2022 1 次提交
  4. 26 3月, 2022 1 次提交
  5. 08 2月, 2022 1 次提交
  6. 19 1月, 2022 1 次提交
  7. 12 1月, 2022 1 次提交
  8. 29 12月, 2021 1 次提交
    • R
      drm/amdgpu: Don't inherit GEM object VMAs in child process · fbcdbfde
      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.
      
      To limit the impact of the change to user space consumers such as OpenGL
      etc, limit it to KFD BOs only.
      Acked-by: NFelix Kuehling <Felix.Kuehling@amd.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NDavid Yat Sin <david.yatsin@amd.com>
      Signed-off-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      fbcdbfde
  9. 25 11月, 2021 1 次提交
  10. 18 11月, 2021 1 次提交
  11. 05 11月, 2021 1 次提交
  12. 08 9月, 2021 1 次提交
  13. 01 9月, 2021 1 次提交
  14. 26 8月, 2021 1 次提交
  15. 03 8月, 2021 1 次提交
  16. 29 7月, 2021 1 次提交
  17. 16 7月, 2021 1 次提交
  18. 13 7月, 2021 2 次提交
  19. 22 6月, 2021 1 次提交
  20. 16 6月, 2021 1 次提交
  21. 06 6月, 2021 2 次提交
  22. 05 6月, 2021 1 次提交
  23. 27 5月, 2021 1 次提交
    • T
      drm/amdgpu: Implement mmap as GEM object function · 71df0368
      Thomas Zimmermann 提交于
      Moving the driver-specific mmap code into a GEM object function allows
      for using DRM helpers for various mmap callbacks.
      
      This change resolves several inconsistencies between regular mmap and
      prime-based mmap. The vm_ops field in vma is now set for all mmap'ed
      areas. Previously it way only set for regular mmap calls, prime-based
      mmap used TTM's default vm_ops. The function amdgpu_verify_access() is
      no longer being called and therefore removed by this patch.
      
      As a side effect, amdgpu_ttm_vm_ops and amdgpu_ttm_fault() are now
      implemented in amdgpu's GEM code.
      
      v4:
      	* rebased
      v3:
      	* rename mmap function to amdgpu_gem_object_mmap() (Christian)
      	* remove unnecessary checks from mmap (Christian)
      v2:
      	* rename amdgpu_ttm_vm_ops and amdgpu_ttm_fault() to
      	  amdgpu_gem_vm_ops and amdgpu_gem_fault() (Christian)
      	* the check for kfd_bo has meanwhile been removed
      Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210525151055.8174-3-tzimmermann@suse.de
      71df0368
  24. 23 4月, 2021 1 次提交
  25. 10 4月, 2021 2 次提交
  26. 19 2月, 2021 1 次提交
  27. 03 2月, 2021 1 次提交
  28. 02 2月, 2021 1 次提交
  29. 13 1月, 2021 1 次提交
  30. 10 12月, 2020 1 次提交
  31. 09 12月, 2020 1 次提交
  32. 09 11月, 2020 1 次提交
  33. 27 10月, 2020 1 次提交
  34. 24 10月, 2020 1 次提交
  35. 16 10月, 2020 1 次提交