1. 30 Sep, 2021 1 commit
  2. 29 Sep, 2021 1 commit
  3. 27 Sep, 2021 1 commit
  4. 25 Sep, 2021 1 commit
    • Janusz Krzysztofik's avatar
      drm/i915: Flush buffer pools on driver remove · 74af1e2c
      Janusz Krzysztofik authored
      We currently do an explicit flush of the buffer pools within the call path
      of drm_driver.release(); this removes all buffers, regardless of their age,
      freeing the buffers' associated resources (objects, address space areas).
      However there is other code that runs within the drm_driver.release() call
      chain that expects objects and their associated address space areas have
      already been flushed.
      
      Since buffer pools auto-flush old buffers once per second in a worker
      thread, there's a small window where if we remove the driver while there
      are still objects in buffers with an age of less than one second, the
      assumptions of the other release code may be violated.
      
      By moving the flush to driver remove (which executes earlier via the
      pci_driver.remove() flow) we're ensuring that all buffers are flushed and
      their associated objects freed before some other code in
      pci_driver.remove() flushes those objects so they are released before
      _any_ code in drm_driver.release() that check completness of those
      flushes executes.
      
      v2: Reword commit description as suggested by Matt.
      Signed-off-by: default avatarJanusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210924163825.634606-1-janusz.krzysztofik@linux.intel.com
      74af1e2c
  5. 24 Sep, 2021 11 commits
  6. 23 Sep, 2021 2 commits
  7. 22 Sep, 2021 7 commits
  8. 21 Sep, 2021 2 commits
  9. 20 Sep, 2021 8 commits
  10. 19 Sep, 2021 4 commits
  11. 17 Sep, 2021 1 commit
    • Maarten Lankhorst's avatar
      kernel/locking: Add context to ww_mutex_trylock() · 12235da8
      Maarten Lankhorst authored
      i915 will soon gain an eviction path that trylock a whole lot of locks
      for eviction, getting dmesg failures like below:
      
        BUG: MAX_LOCK_DEPTH too low!
        turning off the locking correctness validator.
        depth: 48  max: 48!
        48 locks held by i915_selftest/5776:
         #0: ffff888101a79240 (&dev->mutex){....}-{3:3}, at: __driver_attach+0x88/0x160
         #1: ffffc900009778c0 (reservation_ww_class_acquire){+.+.}-{0:0}, at: i915_vma_pin.constprop.63+0x39/0x1b0 [i915]
         #2: ffff88800cf74de8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.63+0x5f/0x1b0 [i915]
         #3: ffff88810c7f9e38 (&vm->mutex/1){+.+.}-{3:3}, at: i915_vma_pin_ww+0x1c4/0x9d0 [i915]
         #4: ffff88810bad5768 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915]
         #5: ffff88810bad60e8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915]
        ...
         #46: ffff88811964d768 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915]
         #47: ffff88811964e0e8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915]
        INFO: lockdep is turned off.
      
      Fixing eviction to nest into ww_class_acquire is a high priority, but
      it requires a rework of the entire driver, which can only be done one
      step at a time.
      
      As an intermediate solution, add an acquire context to
      ww_mutex_trylock, which allows us to do proper nesting annotations on
      the trylocks, making the above lockdep splat disappear.
      
      This is also useful in regulator_lock_nested, which may avoid dropping
      regulator_nesting_mutex in the uncontended path, so use it there.
      
      TTM may be another user for this, where we could lock a buffer in a
      fastpath with list locks held, without dropping all locks we hold.
      
      [peterz: rework actual ww_mutex_trylock() implementations]
      Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Link: https://lkml.kernel.org/r/YUBGPdDDjKlxAuXJ@hirez.programming.kicks-ass.net
      12235da8
  12. 16 Sep, 2021 1 commit