1. 22 7月, 2021 10 次提交
  2. 17 7月, 2021 7 次提交
  3. 16 7月, 2021 3 次提交
  4. 15 7月, 2021 1 次提交
  5. 14 7月, 2021 3 次提交
    • Z
      drm/ttm: add a check against null pointer dereference · 9e5c7729
      Zheyu Ma 提交于
      When calling ttm_range_man_fini(), 'man' may be uninitialized, which may
      cause a null pointer dereference bug.
      
      Fix this by checking if it is a null pointer.
      
      This log reveals it:
      
      [    7.902580 ] BUG: kernel NULL pointer dereference, address: 0000000000000058
      [    7.905721 ] RIP: 0010:ttm_range_man_fini+0x40/0x160
      [    7.911826 ] Call Trace:
      [    7.911826 ]  radeon_ttm_fini+0x167/0x210
      [    7.911826 ]  radeon_bo_fini+0x15/0x40
      [    7.913767 ]  rs400_fini+0x55/0x80
      [    7.914358 ]  radeon_device_fini+0x3c/0x140
      [    7.914358 ]  radeon_driver_unload_kms+0x5c/0xe0
      [    7.914358 ]  radeon_driver_load_kms+0x13a/0x200
      [    7.914358 ]  ? radeon_driver_unload_kms+0xe0/0xe0
      [    7.914358 ]  drm_dev_register+0x1db/0x290
      [    7.914358 ]  radeon_pci_probe+0x16a/0x230
      [    7.914358 ]  local_pci_probe+0x4a/0xb0
      Signed-off-by: NZheyu Ma <zheyuma97@gmail.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1626274459-8148-1-git-send-email-zheyuma97@gmail.comSigned-off-by: NChristian König <christian.koenig@amd.com>
      9e5c7729
    • M
      drm/i915/gtt: drop the page table optimisation · 0abb33bf
      Matthew Auld 提交于
      We skip filling out the pt with scratch entries if the va range covers
      the entire pt, since we later have to fill it with the PTEs for the
      object pages anyway. However this might leave open a small window where
      the PTEs don't point to anything valid for the HW to consume.
      
      When for example using 2M GTT pages this fill_px() showed up as being
      quite significant in perf measurements, and ends up being completely
      wasted since we ignore the pt and just use the pde directly.
      
      Anyway, currently we have our PTE construction split between alloc and
      insert, which is probably slightly iffy nowadays, since the alloc
      doesn't actually allocate anything anymore, instead it just sets up the
      page directories and points the PTEs at the scratch page. Later when we
      do the insert step we re-program the PTEs again. Better might be to
      squash the alloc and insert into a single step, then bringing back this
      optimisation(along with some others) should be possible.
      
      Fixes: 14826673 ("drm/i915: Only initialize partially filled pagetables")
      Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
      Cc: Jon Bloomfield <jon.bloomfield@intel.com>
      Cc: Chris Wilson <chris.p.wilson@intel.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: <stable@vger.kernel.org> # v4.15+
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210713130431.2392740-1-matthew.auld@intel.com
      (cherry picked from commit 8f88ca76)
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      0abb33bf
    • V
      drm/i915/gt: Fix -EDEADLK handling regression · 2feeb528
      Ville Syrjälä 提交于
      The conversion to ww mutexes failed to address the fence code which
      already returns -EDEADLK when we run out of fences. Ww mutexes on
      the other hand treat -EDEADLK as an internal errno value indicating
      a need to restart the operation due to a deadlock. So now when the
      fence code returns -EDEADLK the higher level code erroneously
      restarts everything instead of returning the error to userspace
      as is expected.
      
      To remedy this let's switch the fence code to use a different errno
      value for this. -ENOBUFS seems like a semi-reasonable unique choice.
      Apart from igt the only user of this I could find is sna, and even
      there all we do is dump the current fence registers from debugfs
      into the X server log. So no user visible functionality is affected.
      If we really cared about preserving this we could of course convert
      back to -EDEADLK higher up, but doesn't seem like that's worth
      the hassle here.
      
      Not quite sure which commit specifically broke this, but I'll
      just attribute it to the general gem ww mutex work.
      
      Cc: stable@vger.kernel.org
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Thomas Hellström <thomas.hellstrom@intel.com>
      Testcase: igt/gem_pread/exhaustion
      Testcase: igt/gem_pwrite/basic-exhaustion
      Testcase: igt/gem_fenced_exec_thrash/too-many-fences
      Fixes: 80f0b679 ("drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.")
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210630164413.25481-1-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      (cherry picked from commit 78d2ad7e)
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      2feeb528
  6. 13 7月, 2021 16 次提交