Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 27 11月, 2015 3 次提交
  3. 26 11月, 2015 1 次提交
  5. 23 11月, 2015 2 次提交
  7. 19 11月, 2015 1 次提交
  9. 18 11月, 2015 7 次提交
  11. 16 11月, 2015 1 次提交
  13. 12 11月, 2015 3 次提交
  15. 10 11月, 2015 1 次提交
  17. 04 11月, 2015 1 次提交
  19. 02 11月, 2015 1 次提交
  21. 29 10月, 2015 2 次提交
  23. 26 10月, 2015 1 次提交
  25. 23 10月, 2015 1 次提交
  27. 22 10月, 2015 3 次提交
  29. 21 10月, 2015 3 次提交
  31. 13 10月, 2015 3 次提交
  33. 10 10月, 2015 1 次提交
  35. 09 10月, 2015 1 次提交
  37. 07 10月, 2015 3 次提交
  39. 06 10月, 2015 1 次提交
    • T
      drm/i915: Clean up associated VMAs on context destruction · e9f24d5f
      由 Tvrtko Ursulin 提交于 
      Prevent leaking VMAs and PPGTT VMs when objects are imported
via flink.

Scenario is that any VMAs created by the importer will be left
dangling after the importer exits, or destroys the PPGTT context
with which they are associated.

This is caused by object destruction not running when the
importer closes the buffer object handle due the reference held
by the exporter. This also leaks the VM since the VMA has a
reference on it.

In practice these leaks can be observed by stopping and starting
the X server on a kernel with fbcon compiled in. Every time
X server exits another VMA will be leaked against the fbcon's
frame buffer object.

Also on systems where flink buffer sharing is used extensively,
like Android, this leak has even more serious consequences.

This version is takes a general approach from the  earlier work
by Rafael Barbalho (drm/i915: Clean-up PPGTT on context
destruction) and tries to incorporate the subsequent discussion
between Chris Wilson and Daniel Vetter.

v2:

Removed immediate cleanup on object retire - it was causing a
recursive VMA unbind via i915_gem_object_wait_rendering. And
it is in fact not even needed since by definition context
cleanup worker runs only after the last context reference has
been dropped, hence all VMAs against the VM belonging to the
context are already on the inactive list.

v3:

Previous version could deadlock since VMA unbind waits on any
rendering on an object to complete. Objects can be busy in a
different VM which would mean that the cleanup loop would do
the wait with the struct mutex held.

This is an even simpler approach where we just unbind VMAs
without waiting since we know all VMAs belonging to this VM
are idle, and there is nothing in flight, at the point
context destructor runs.

v4:

Double underscore prefix for __915_vma_unbind_no_wait and a
commit message typo fix. (Michel Thierry)

Note that this is just a partial/interim fix since we have a bit a
fundamental issue with cleaning up, e.g.

https://bugs.freedesktop.org/show_bug.cgi?id=87729Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Testcase: igt/gem_ppgtt.c/flink-and-exit-vma-leak
Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rafael Barbalho <rafael.barbalho@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
[danvet: Add a note that this isn't everything.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e9f24d5f