1. 02 10月, 2019 1 次提交
    • C
      drm/i915/userptr: Never allow userptr into the mappable GGTT · a4311745
      Chris Wilson 提交于
      Daniel Vetter uncovered a nasty cycle in using the mmu-notifiers to
      invalidate userptr objects which also happen to be pulled into GGTT
      mmaps. That is when we unbind the userptr object (on mmu invalidation),
      we revoke all CPU mmaps, which may then recurse into mmu invalidation.
      
      We looked for ways of breaking the cycle, but the revocation on
      invalidation is required and cannot be avoided. The only solution we
      could see was to not allow such GGTT bindings of userptr objects in the
      first place. In practice, no one really wants to use a GGTT mmapping of
      a CPU pointer...
      
      Just before Daniel's explosive lockdep patches land in v5.4-rc1, we got
      a genuine blip from CI:
      
      <4>[  246.793958] ======================================================
      <4>[  246.793972] WARNING: possible circular locking dependency detected
      <4>[  246.793989] 5.3.0-gbd6c56f50d15-drmtip_372+ #1 Tainted: G     U
      <4>[  246.794003] ------------------------------------------------------
      <4>[  246.794017] kswapd0/145 is trying to acquire lock:
      <4>[  246.794030] 000000003f565be6 (&dev->struct_mutex/1){+.+.}, at: userptr_mn_invalidate_range_start+0x18f/0x220 [i915]
      <4>[  246.794250]
                        but task is already holding lock:
      <4>[  246.794263] 000000001799cef9 (&anon_vma->rwsem){++++}, at: page_lock_anon_vma_read+0xe6/0x2a0
      <4>[  246.794291]
                        which lock already depends on the new lock.
      
      <4>[  246.794307]
                        the existing dependency chain (in reverse order) is:
      <4>[  246.794322]
                        -> #3 (&anon_vma->rwsem){++++}:
      <4>[  246.794344]        down_write+0x33/0x70
      <4>[  246.794357]        __vma_adjust+0x3d9/0x7b0
      <4>[  246.794370]        __split_vma+0x16a/0x180
      <4>[  246.794385]        mprotect_fixup+0x2a5/0x320
      <4>[  246.794399]        do_mprotect_pkey+0x208/0x2e0
      <4>[  246.794413]        __x64_sys_mprotect+0x16/0x20
      <4>[  246.794429]        do_syscall_64+0x55/0x1c0
      <4>[  246.794443]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      <4>[  246.794456]
                        -> #2 (&mapping->i_mmap_rwsem){++++}:
      <4>[  246.794478]        down_write+0x33/0x70
      <4>[  246.794493]        unmap_mapping_pages+0x48/0x130
      <4>[  246.794519]        i915_vma_revoke_mmap+0x81/0x1b0 [i915]
      <4>[  246.794519]        i915_vma_unbind+0x11d/0x4a0 [i915]
      <4>[  246.794519]        i915_vma_destroy+0x31/0x300 [i915]
      <4>[  246.794519]        __i915_gem_free_objects+0xb8/0x4b0 [i915]
      <4>[  246.794519]        drm_file_free.part.0+0x1e6/0x290
      <4>[  246.794519]        drm_release+0xa6/0xe0
      <4>[  246.794519]        __fput+0xc2/0x250
      <4>[  246.794519]        task_work_run+0x82/0xb0
      <4>[  246.794519]        do_exit+0x35b/0xdb0
      <4>[  246.794519]        do_group_exit+0x34/0xb0
      <4>[  246.794519]        __x64_sys_exit_group+0xf/0x10
      <4>[  246.794519]        do_syscall_64+0x55/0x1c0
      <4>[  246.794519]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      <4>[  246.794519]
                        -> #1 (&vm->mutex){+.+.}:
      <4>[  246.794519]        i915_gem_shrinker_taints_mutex+0x6d/0xe0 [i915]
      <4>[  246.794519]        i915_address_space_init+0x9f/0x160 [i915]
      <4>[  246.794519]        i915_ggtt_init_hw+0x55/0x170 [i915]
      <4>[  246.794519]        i915_driver_probe+0xc9f/0x1620 [i915]
      <4>[  246.794519]        i915_pci_probe+0x43/0x1b0 [i915]
      <4>[  246.794519]        pci_device_probe+0x9e/0x120
      <4>[  246.794519]        really_probe+0xea/0x3d0
      <4>[  246.794519]        driver_probe_device+0x10b/0x120
      <4>[  246.794519]        device_driver_attach+0x4a/0x50
      <4>[  246.794519]        __driver_attach+0x97/0x130
      <4>[  246.794519]        bus_for_each_dev+0x74/0xc0
      <4>[  246.794519]        bus_add_driver+0x13f/0x210
      <4>[  246.794519]        driver_register+0x56/0xe0
      <4>[  246.794519]        do_one_initcall+0x58/0x300
      <4>[  246.794519]        do_init_module+0x56/0x1f6
      <4>[  246.794519]        load_module+0x25bd/0x2a40
      <4>[  246.794519]        __se_sys_finit_module+0xd3/0xf0
      <4>[  246.794519]        do_syscall_64+0x55/0x1c0
      <4>[  246.794519]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      <4>[  246.794519]
                        -> #0 (&dev->struct_mutex/1){+.+.}:
      <4>[  246.794519]        __lock_acquire+0x15d8/0x1e90
      <4>[  246.794519]        lock_acquire+0xa6/0x1c0
      <4>[  246.794519]        __mutex_lock+0x9d/0x9b0
      <4>[  246.794519]        userptr_mn_invalidate_range_start+0x18f/0x220 [i915]
      <4>[  246.794519]        __mmu_notifier_invalidate_range_start+0x85/0x110
      <4>[  246.794519]        try_to_unmap_one+0x76b/0x860
      <4>[  246.794519]        rmap_walk_anon+0x104/0x280
      <4>[  246.794519]        try_to_unmap+0xc0/0xf0
      <4>[  246.794519]        shrink_page_list+0x561/0xc10
      <4>[  246.794519]        shrink_inactive_list+0x220/0x440
      <4>[  246.794519]        shrink_node_memcg+0x36e/0x740
      <4>[  246.794519]        shrink_node+0xcb/0x490
      <4>[  246.794519]        balance_pgdat+0x241/0x580
      <4>[  246.794519]        kswapd+0x16c/0x530
      <4>[  246.794519]        kthread+0x119/0x130
      <4>[  246.794519]        ret_from_fork+0x24/0x50
      <4>[  246.794519]
                        other info that might help us debug this:
      
      <4>[  246.794519] Chain exists of:
                          &dev->struct_mutex/1 --> &mapping->i_mmap_rwsem --> &anon_vma->rwsem
      
      <4>[  246.794519]  Possible unsafe locking scenario:
      
      <4>[  246.794519]        CPU0                    CPU1
      <4>[  246.794519]        ----                    ----
      <4>[  246.794519]   lock(&anon_vma->rwsem);
      <4>[  246.794519]                                lock(&mapping->i_mmap_rwsem);
      <4>[  246.794519]                                lock(&anon_vma->rwsem);
      <4>[  246.794519]   lock(&dev->struct_mutex/1);
      <4>[  246.794519]
                         *** DEADLOCK ***
      
      v2: Say no to mmap_ioctl
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111744
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111870Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190928082546.3473-1-chris@chris-wilson.co.uk
      a4311745
  2. 03 9月, 2019 1 次提交
    • C
      drm/i915: Replace obj->pin_global with obj->frontbuffer · 5a90606d
      Chris Wilson 提交于
      obj->pin_global was originally used as a means to keep the shrinker off
      the active scanout, but we use the vma->pin_count itself for that and
      the obj->frontbuffer to delay shrinking active framebuffers. The other
      role that obj->pin_global gained was for spotting display objects inside
      GEM and working harder to keep those coherent; for which we can again
      simply inspect obj->frontbuffer directly.
      
      Coming up next, we will want to manipulate the pin_global counter
      outside of the principle locks, so would need to make pin_global atomic.
      However, since obj->frontbuffer is already managed atomically, it makes
      sense to use that the primary key for display objects instead of having
      pin_global.
      
      Ville pointed out the principle difference is that obj->frontbuffer is
      set for as long as an intel_framebuffer is attached to an object, but
      obj->pin_global was only raised for as long as the object was active. In
      practice, this means that we consider the object as being on the scanout
      for longer than is strictly required, causing us to be more proactive in
      flushing -- though it should be true that we would have flushed
      eventually when the back became the front, except that on the flip path
      that flush is async but when hit from another ioctl it will be
      synchronous.
      
      v2: i915_gem_object_is_framebuffer()
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190902040303.14195-5-chris@chris-wilson.co.uk
      5a90606d
  3. 16 8月, 2019 1 次提交
  4. 13 8月, 2019 1 次提交
  5. 03 8月, 2019 1 次提交
    • C
      drm/i915: Hide unshrinkable context objects from the shrinker · 1aff1903
      Chris Wilson 提交于
      The shrinker cannot touch objects used by the contexts (logical state
      and ring). Currently we mark those as "pin_global" to let the shrinker
      skip over them, however, if we remove them from the shrinker lists
      entirely, we don't event have to include them in our shrink accounting.
      
      By keeping the unshrinkable objects in our shrinker tracking, we report
      a large number of objects available to be shrunk, and leave the shrinker
      deeply unsatisfied when we fail to reclaim those. The shrinker will
      persist in trying to reclaim the unavailable objects, forcing the system
      into a livelock (not even hitting the dread oomkiller).
      
      v2: Extend unshrinkable protection for perma-pinned scratch and guc
      allocations (Tvrtko)
      v3: Notice that we should be pinned when marking unshrinkable and so the
      link cannot be empty; merge duplicate paths.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190802212137.22207-1-chris@chris-wilson.co.uk
      1aff1903
  6. 12 7月, 2019 1 次提交
  7. 22 6月, 2019 1 次提交
    • C
      drm/i915: Throw away the active object retirement complexity · a93615f9
      Chris Wilson 提交于
      Remove the accumulated optimisations that we have for i915_vma_retire
      and reduce it to the bare essential of tracking the active object
      reference. This allows us to only use atomic operations, and so will be
      able to avoid the struct_mutex requirement.
      
      The principal loss here is the shrinker MRU bumping, so now if we have
      to shrink, we will do so in much more random order and more likely to
      try and shrink recently used objects. That is a nuisance, but shrinking
      active objects is a second step we try to avoid and will always be a
      system-wide performance issue.
      
      The other loss is here is in the automatic pruning of the
      reservation_object when idling. This is not as large an issue as upon
      reservation_object introduction as now adding new fences into the object
      replaces already signaled fences, keeping the array compact. But we do
      lose the auto-expiration of stale fences and unused arrays. That may be
      a noticeable problem for which we need to re-implement autopruning.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190621183801.23252-3-chris@chris-wilson.co.uk
      a93615f9
  8. 18 6月, 2019 1 次提交
  9. 28 5月, 2019 9 次提交
  10. 31 3月, 2019 1 次提交
  11. 06 3月, 2019 1 次提交
  12. 28 2月, 2019 1 次提交
  13. 06 2月, 2019 1 次提交
  14. 29 1月, 2019 1 次提交
  15. 16 1月, 2019 1 次提交
  16. 09 1月, 2019 1 次提交
  17. 26 7月, 2018 1 次提交
  18. 13 7月, 2018 2 次提交
  19. 29 6月, 2018 3 次提交
  20. 22 2月, 2018 1 次提交
  21. 16 2月, 2018 1 次提交
  22. 04 12月, 2017 1 次提交
    • T
      drm/i915/gvt: Dmabuf support for GVT-g · e546e281
      Tina Zhang 提交于
      This patch introduces a guest's framebuffer sharing mechanism based on
      dma-buf subsystem. With this sharing mechanism, guest's framebuffer can
      be shared between guest VM and host.
      
      v17:
      - modify VFIO_DEVICE_GET_GFX_DMABUF interface. (Alex)
      
      v16:
      - add x_hot and y_hot. (Gerd)
      - add flag validation for VFIO_DEVICE_GET_GFX_DMABUF. (Alex)
      - rebase 4.14.0-rc6.
      
      v15:
      - add VFIO_DEVICE_GET_GFX_DMABUF ABI. (Gerd)
      - add intel_vgpu_dmabuf_cleanup() to clean up the vGPU's dmabuf. (Gerd)
      
      v14:
      - add PROBE, DMABUF and REGION flags. (Alex)
      
      v12:
      - refine the lifecycle of dmabuf.
      
      v9:
      - remove dma-buf management. (Alex)
      - track the dma-buf create and release in kernel mode. (Gerd) (Daniel)
      
      v8:
      - refine the dma-buf ioctl definition.(Alex)
      - add a lock to protect the dmabuf list. (Alex)
      
      v7:
      - release dma-buf related allocations in dma-buf's associated release
        function. (Alex)
      - refine ioctl interface for querying plane info or create dma-buf.
        (Alex)
      
      v6:
      - align the dma-buf life cycle with the vfio device. (Alex)
      - add the dma-buf related operations in a separate patch. (Gerd)
      - i915 related changes. (Chris)
      
      v5:
      - fix bug while checking whether the gem obj is gvt's dma-buf when user
        change caching mode or domains. Add a helper function to do it.
        (Xiaoguang)
      - add definition for the query plane and create dma-buf. (Xiaoguang)
      
      v4:
      - fix bug while checking whether the gem obj is gvt's dma-buf when set
        caching mode or doamins. (Xiaoguang)
      
      v3:
      - declare a new flag I915_GEM_OBJECT_IS_GVT_DMABUF in drm_i915_gem_object
        to represent the gem obj for gvt's dma-buf. The tiling mode, caching
        mode and domains can not be changed for this kind of gem object. (Alex)
      - change dma-buf related information to be more generic. So other vendor
        can use the same interface. (Alex)
      
      v2:
      - create a management fd for dma-buf operations. (Alex)
      - alloc gem object's backing storage in gem obj's get_pages() callback.
        (Chris)
      Signed-off-by: NTina Zhang <tina.zhang@intel.com>
      Cc: Alex Williamson <alex.williamson@redhat.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      e546e281
  23. 14 11月, 2017 1 次提交
  24. 17 10月, 2017 2 次提交
  25. 10 10月, 2017 1 次提交
  26. 07 10月, 2017 3 次提交