1. 18 6月, 2020 1 次提交
  2. 01 5月, 2020 1 次提交
  3. 29 4月, 2020 3 次提交
  4. 14 4月, 2020 1 次提交
    • O
      device_cgroup: Cleanup cgroup eBPF device filter code · eec8fd02
      Odin Ugedal 提交于
      Original cgroup v2 eBPF code for filtering device access made it
      possible to compile with CONFIG_CGROUP_DEVICE=n and still use the eBPF
      filtering. Change
      commit 4b7d4d45 ("device_cgroup: Export devcgroup_check_permission")
      reverted this, making it required to set it to y.
      
      Since the device filtering (and all the docs) for cgroup v2 is no longer
      a "device controller" like it was in v1, someone might compile their
      kernel with CONFIG_CGROUP_DEVICE=n. Then (for linux 5.5+) the eBPF
      filter will not be invoked, and all processes will be allowed access
      to all devices, no matter what the eBPF filter says.
      Signed-off-by: NOdin Ugedal <odin@ugedal.com>
      Acked-by: NRoman Gushchin <guro@fb.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      eec8fd02
  5. 27 2月, 2020 1 次提交
  6. 13 2月, 2020 1 次提交
    • R
      drm/amdkfd: refactor runtime pm for baco · 9593f4d6
      Rajneesh Bhardwaj 提交于
      So far the kfd driver implemented same routines for runtime and system
      wide suspend and resume (s2idle or mem). During system wide suspend the
      kfd aquires an atomic lock that prevents any more user processes to
      create queues and interact with kfd driver and amd gpu. This mechanism
      created problem when amdgpu device is runtime suspended with BACO
      enabled. Any application that relies on kfd driver fails to load because
      the driver reports a locked kfd device since gpu is runtime suspended.
      
      However, in an ideal case, when gpu is runtime  suspended the kfd driver
      should be able to:
      
       - auto resume amdgpu driver whenever a client requests compute service
       - prevent runtime suspend for amdgpu  while kfd is in use
      
      This change refactors the amdgpu and amdkfd drivers to support BACO and
      runtime power management.
      Reviewed-by: NOak Zeng <oak.zeng@amd.com>
      Reviewed-by: NFelix Kuehling <felix.kuehling@amd.com>
      Signed-off-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      9593f4d6
  7. 07 2月, 2020 1 次提交
  8. 08 1月, 2020 1 次提交
  9. 23 11月, 2019 1 次提交
  10. 14 11月, 2019 4 次提交
  11. 10 10月, 2019 1 次提交
  12. 08 10月, 2019 1 次提交
    • H
      drm/amdkfd: Check against device cgroup · 6b855f7b
      Harish Kasiviswanathan 提交于
      Participate in device cgroup. All kfd devices are exposed via /dev/kfd.
      So use /dev/dri/renderN node.
      
      Before exposing the device to a task check if it has permission to
      access it. If the task (based on its cgroup) can access /dev/dri/renderN
      then expose the device via kfd node.
      
      If the task cannot access /dev/dri/renderN then process device data
      (pdd) is not created. This will ensure that task cannot use the device.
      
      In sysfs topology, all device nodes are visible irrespective of the task
      cgroup. The sysfs node directories are created at driver load time and
      cannot be changed dynamically. However, access to information inside
      nodes is controlled based on the task's cgroup permissions.
      Signed-off-by: NHarish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
      Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      6b855f7b
  13. 03 10月, 2019 3 次提交
  14. 22 8月, 2019 1 次提交
  15. 20 8月, 2019 1 次提交
  16. 17 7月, 2019 1 次提交
  17. 04 7月, 2019 1 次提交
  18. 22 6月, 2019 1 次提交
  19. 21 6月, 2019 1 次提交
  20. 12 6月, 2019 2 次提交
  21. 29 5月, 2019 4 次提交
  22. 25 5月, 2019 5 次提交
  23. 21 5月, 2019 1 次提交
  24. 20 3月, 2019 1 次提交
  25. 19 2月, 2019 1 次提交