1. 09 Dec, 2019 18 commits
  2. 08 Dec, 2019 1 commit
  3. 07 Dec, 2019 3 commits
    • Chris Wilson's avatar
      drm/i915/gtt: Account for preallocation in asserts · ca5930b1
      Chris Wilson authored
      Our asserts allow for the PDEs to be allocated concurrently, but we did
      not account for the aliasing-ppgtt to be preallocated on top.
      
      Testcase: igt/gem_ppgtt #bsw
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Acked-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191207221453.2802627-1-chris@chris-wilson.co.uk
      ca5930b1
    • Chris Wilson's avatar
      drm/i915: Avoid calling i915_gem_object_unbind holding object lock · 8b1c78e0
      Chris Wilson authored
      In the extreme case, we may wish to wait on an rcu-barrier to reap stale
      vm to purge the last of the object bindings. However, we are not allowed
      to use rcu_barrier() beneath the dma_resv (i.e. object) lock and do not
      take lightly the prospect of unlocking a mutex deep in the bowels of the
      routine. i915_gem_object_unbind() itself does not need the object lock,
      and it turns out the callers do not need to the unbind as part of a
      locked sequence around set-cache-level, so rearrange the code to avoid
      taking the object lock in the callers.
      
      <4> [186.816311] ======================================================
      <4> [186.816313] WARNING: possible circular locking dependency detected
      <4> [186.816316] 5.4.0-rc8-CI-CI_DRM_7486+ #1 Tainted: G     U
      <4> [186.816318] ------------------------------------------------------
      <4> [186.816320] perf_pmu/1321 is trying to acquire lock:
      <4> [186.816322] ffff88849487c4d8 (&mm->mmap_sem#2){++++}, at: __might_fault+0x39/0x90
      <4> [186.816331]
      but task is already holding lock:
      <4> [186.816333] ffffe8ffffa05008 (&cpuctx_mutex){+.+.}, at: perf_event_ctx_lock_nested+0xa9/0x1b0
      <4> [186.816339]
      which lock already depends on the new lock.
      
      <4> [186.816341]
      the existing dependency chain (in reverse order) is:
      <4> [186.816343]
      -> #6 (&cpuctx_mutex){+.+.}:
      <4> [186.816349]        __mutex_lock+0x9a/0x9d0
      <4> [186.816352]        perf_event_init_cpu+0xa4/0x140
      <4> [186.816357]        perf_event_init+0x19d/0x1cd
      <4> [186.816362]        start_kernel+0x372/0x4f4
      <4> [186.816365]        secondary_startup_64+0xa4/0xb0
      <4> [186.816381]
      -> #5 (pmus_lock){+.+.}:
      <4> [186.816385]        __mutex_lock+0x9a/0x9d0
      <4> [186.816387]        perf_event_init_cpu+0x6b/0x140
      <4> [186.816404]        cpuhp_invoke_callback+0x9b/0x9d0
      <4> [186.816406]        _cpu_up+0xa2/0x140
      <4> [186.816409]        do_cpu_up+0x61/0xa0
      <4> [186.816411]        smp_init+0x57/0x96
      <4> [186.816413]        kernel_init_freeable+0xac/0x1c7
      <4> [186.816416]        kernel_init+0x5/0x100
      <4> [186.816419]        ret_from_fork+0x24/0x50
      <4> [186.816421]
      -> #4 (cpu_hotplug_lock.rw_sem){++++}:
      <4> [186.816424]        cpus_read_lock+0x34/0xd0
      <4> [186.816427]        rcu_barrier+0xaa/0x190
      <4> [186.816429]        kernel_init+0x21/0x100
      <4> [186.816431]        ret_from_fork+0x24/0x50
      <4> [186.816433]
      -> #3 (rcu_state.barrier_mutex){+.+.}:
      <4> [186.816436]        __mutex_lock+0x9a/0x9d0
      <4> [186.816438]        rcu_barrier+0x23/0x190
      <4> [186.816502]        i915_gem_object_unbind+0x3a6/0x400 [i915]
      <4> [186.816537]        i915_gem_object_set_cache_level+0x32/0x90 [i915]
      <4> [186.816571]        i915_gem_object_pin_to_display_plane+0x5d/0x160 [i915]
      <4> [186.816612]        intel_pin_and_fence_fb_obj+0x9e/0x200 [i915]
      <4> [186.816679]        intel_plane_pin_fb+0x3f/0xd0 [i915]
      <4> [186.816717]        intel_prepare_plane_fb+0x130/0x520 [i915]
      <4> [186.816722]        drm_atomic_helper_prepare_planes+0x85/0x110
      <4> [186.816761]        intel_atomic_commit+0xc6/0x350 [i915]
      <4> [186.816764]        drm_atomic_helper_update_plane+0xed/0x110
      <4> [186.816768]        setplane_internal+0x97/0x190
      <4> [186.816770]        drm_mode_setplane+0xcd/0x190
      <4> [186.816773]        drm_ioctl_kernel+0xa7/0xf0
      <4> [186.816775]        drm_ioctl+0x2e1/0x390
      <4> [186.816778]        do_vfs_ioctl+0xa0/0x6f0
      <4> [186.816780]        ksys_ioctl+0x35/0x60
      <4> [186.816782]        __x64_sys_ioctl+0x11/0x20
      <4> [186.816785]        do_syscall_64+0x4f/0x210
      <4> [186.816787]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      <4> [186.816789]
      -> #2 (reservation_ww_class_mutex){+.+.}:
      <4> [186.816793]        __ww_mutex_lock.constprop.15+0xc3/0x1090
      <4> [186.816795]        ww_mutex_lock+0x39/0x70
      <4> [186.816798]        dma_resv_lockdep+0x10e/0x1f7
      <4> [186.816800]        do_one_initcall+0x58/0x2ff
      <4> [186.816802]        kernel_init_freeable+0x137/0x1c7
      <4> [186.816804]        kernel_init+0x5/0x100
      <4> [186.816806]        ret_from_fork+0x24/0x50
      <4> [186.816808]
      -> #1 (reservation_ww_class_acquire){+.+.}:
      <4> [186.816811]        dma_resv_lockdep+0xec/0x1f7
      <4> [186.816813]        do_one_initcall+0x58/0x2ff
      <4> [186.816815]        kernel_init_freeable+0x137/0x1c7
      <4> [186.816817]        kernel_init+0x5/0x100
      <4> [186.816819]        ret_from_fork+0x24/0x50
      <4> [186.816820]
      -> #0 (&mm->mmap_sem#2){++++}:
      <4> [186.816824]        __lock_acquire+0x1328/0x15d0
      <4> [186.816826]        lock_acquire+0xa7/0x1c0
      <4> [186.816828]        __might_fault+0x63/0x90
      <4> [186.816831]        _copy_to_user+0x1e/0x80
      <4> [186.816834]        perf_read+0x200/0x2b0
      <4> [186.816836]        vfs_read+0x96/0x160
      <4> [186.816838]        ksys_read+0x9f/0xe0
      <4> [186.816839]        do_syscall_64+0x4f/0x210
      <4> [186.816841]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      <4> [186.816843]
      other info that might help us debug this:
      
      <4> [186.816846] Chain exists of:
        &mm->mmap_sem#2 --> pmus_lock --> &cpuctx_mutex
      
      <4> [186.816849]  Possible unsafe locking scenario:
      
      <4> [186.816851]        CPU0                    CPU1
      <4> [186.816853]        ----                    ----
      <4> [186.816854]   lock(&cpuctx_mutex);
      <4> [186.816856]                                lock(pmus_lock);
      <4> [186.816858]                                lock(&cpuctx_mutex);
      <4> [186.816860]   lock(&mm->mmap_sem#2);
      <4> [186.816861]
       *** DEADLOCK ***
      
      Closes: https://gitlab.freedesktop.org/drm/intel/issues/728Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarAndi Shyti <andi.shyti@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191206105527.1130413-5-chris@chris-wilson.co.uk
      8b1c78e0
    • Matthew Brost's avatar
      drm/i915/guc: Update uncore access path in flush_ggtt_writes · a22198a9
      Matthew Brost authored
      The preferred way to access the uncore is through the GT structure.
      Update the GuC function, flush_ggtt_writes, to use this path.
      Signed-off-by: default avatarMatthew Brost <matthew.brost@intel.com>
      Signed-off-by: default avatarJohn Harrison <john.c.harrison@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191207010033.24667-1-John.C.Harrison@Intel.com
      a22198a9
  4. 06 Dec, 2019 14 commits
  5. 05 Dec, 2019 4 commits
    • Chris Wilson's avatar
      drm/i915: Serialise i915_active_acquire() with __active_retire() · bbca083d
      Chris Wilson authored
      As __active_retire() does it's final atomic_dec() under the
      ref->tree_lock spinlock, in order to prevent ourselves from reusing the
      ref->cache and ref->tree as they are being destroyed, we need to
      serialise with the retirement during i915_active_acquire().
      
      [  +0.000005] kernel BUG at drivers/gpu/drm/i915/i915_active.c:157!
      [  +0.000011] invalid opcode: 0000 [#1] SMP
      [  +0.000004] CPU: 7 PID: 188 Comm: kworker/u16:4 Not tainted 5.4.0-rc8-03070-gac5e57322614 #89
      [  +0.000002] Hardware name: Razer Razer Blade Stealth 13 Late 2019/LY320, BIOS 1.02 09/10/2019
      [  +0.000082] Workqueue: events_unbound active_work [i915]
      [  +0.000059] RIP: 0010:__active_retire+0x115/0x120 [i915]
      [  +0.000003] Code: 75 28 48 8b 3d 8c 6e 1a 00 48 89 ee e8 e4 5f a5 c0 48 8b 44 24 10 65 48 33 04 25 28 00 00 00 75 0f 48 83 c4 18 5b 5d 41 5c c3 <0f> 0b 0f 0b 0f 0b e8 a0 90 87 c0 0f 1f 44 00 00 48 8b 3d 54 6e 1a
      [  +0.000002] RSP: 0018:ffffb833003f7e48 EFLAGS: 00010286
      [  +0.000003] RAX: ffff8d6e8d726d00 RBX: ffff8d6f9db4e840 RCX: 0000000000000000
      [  +0.000001] RDX: ffffffff82605930 RSI: ffff8d6f9adc4908 RDI: ffff8d6e96cefe28
      [  +0.000002] RBP: ffff8d6e96cefe00 R08: 0000000000000000 R09: ffff8d6f9ffe9a50
      [  +0.000002] R10: 0000000000000048 R11: 0000000000000018 R12: ffff8d6f9adc4930
      [  +0.000001] R13: ffff8d6f9e04fb00 R14: 0000000000000000 R15: ffff8d6f9adc4988
      [  +0.000002] FS:  0000000000000000(0000) GS:ffff8d6f9ffc0000(0000) knlGS:0000000000000000
      [  +0.000002] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  +0.000002] CR2: 000055eb5a34cf10 CR3: 000000018d609002 CR4: 0000000000760ee0
      [  +0.000002] PKRU: 55555554
      [  +0.000001] Call Trace:
      [  +0.000010]  process_one_work+0x1aa/0x350
      [  +0.000004]  worker_thread+0x4d/0x3a0
      [  +0.000004]  kthread+0xfb/0x130
      [  +0.000004]  ? process_one_work+0x350/0x350
      [  +0.000003]  ? kthread_park+0x90/0x90
      [  +0.000005]  ret_from_fork+0x1f/0x40
      Reported-by: default avatarKenneth Graunke <kenneth@whitecape.org>
      Fixes: c9ad602f ("drm/i915: Split i915_active.mutex into an irq-safe spinlock for the rbtree")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Kenneth Graunke <kenneth@whitecape.org>
      Cc: Matthew Auld <matthew.auld@intel.com>
      Tested-by: default avatarKenneth Graunke <kenneth@whitecape.org>
      Reviewed-by: default avatarKenneth Graunke <kenneth@whitecape.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191205183332.801237-1-chris@chris-wilson.co.uk
      bbca083d
    • Andi Shyti's avatar
      drm/i915/gt: Replace I915_READ with intel_uncore_read · 92c964ca
      Andi Shyti authored
      Get rid of the last remaining I915_READ in gt/ and make gt-land
      the first I915_READ-free happy island.
      Suggested-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarAndi Shyti <andi.shyti@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191205164422.727968-1-chris@chris-wilson.co.uk
      92c964ca
    • Chris Wilson's avatar
      drm/i915/gt: Save irqstate around virtual_context_destroy · 6f7ac828
      Chris Wilson authored
      As virtual_context_destroy() may be called from a request signal, it may
      be called from inside an irq-off section, and so we need to do a full
      save/restore of the irq state rather than blindly re-enable irqs upon
      unlocking.
      
      <4> [110.024262] WARNING: inconsistent lock state
      <4> [110.024277] 5.4.0-rc8-CI-CI_DRM_7489+ #1 Tainted: G     U
      <4> [110.024292] --------------------------------
      <4> [110.024305] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
      <4> [110.024323] kworker/0:0/5 [HC0[0]:SC0[0]:HE1:SE1] takes:
      <4> [110.024338] ffff88826a0c7a18 (&(&rq->lock)->rlock){?.-.}, at: i915_request_retire+0x221/0x930 [i915]
      <4> [110.024592] {IN-HARDIRQ-W} state was registered at:
      <4> [110.024612]   lock_acquire+0xa7/0x1c0
      <4> [110.024627]   _raw_spin_lock_irqsave+0x33/0x50
      <4> [110.024788]   intel_engine_breadcrumbs_irq+0x38c/0x600 [i915]
      <4> [110.024808]   irq_work_run_list+0x49/0x70
      <4> [110.024824]   irq_work_run+0x26/0x50
      <4> [110.024839]   smp_irq_work_interrupt+0x44/0x1e0
      <4> [110.024855]   irq_work_interrupt+0xf/0x20
      <4> [110.024871]   __do_softirq+0xb7/0x47f
      <4> [110.024885]   irq_exit+0xba/0xc0
      <4> [110.024898]   do_IRQ+0x83/0x160
      <4> [110.024910]   ret_from_intr+0x0/0x1d
      <4> [110.024922] irq event stamp: 172864
      <4> [110.024938] hardirqs last  enabled at (172863): [<ffffffff819ea214>] _raw_spin_unlock_irq+0x24/0x50
      <4> [110.024963] hardirqs last disabled at (172864): [<ffffffff819e9fba>] _raw_spin_lock_irq+0xa/0x40
      <4> [110.024988] softirqs last  enabled at (172812): [<ffffffff81c00385>] __do_softirq+0x385/0x47f
      <4> [110.025012] softirqs last disabled at (172797): [<ffffffff810b829a>] irq_exit+0xba/0xc0
      <4> [110.025031]
      other info that might help us debug this:
      <4> [110.025049]  Possible unsafe locking scenario:
      
      <4> [110.025065]        CPU0
      <4> [110.025075]        ----
      <4> [110.025084]   lock(&(&rq->lock)->rlock);
      <4> [110.025099]   <Interrupt>
      <4> [110.025109]     lock(&(&rq->lock)->rlock);
      <4> [110.025124]
       *** DEADLOCK ***
      
      <4> [110.025144] 4 locks held by kworker/0:0/5:
      <4> [110.025156]  #0: ffff88827588f528 ((wq_completion)events){+.+.}, at: process_one_work+0x1de/0x620
      <4> [110.025187]  #1: ffffc9000006fe78 ((work_completion)(&engine->retire_work)){+.+.}, at: process_one_work+0x1de/0x620
      <4> [110.025219]  #2: ffff88825605e270 (&kernel#2){+.+.}, at: engine_retire+0x57/0xe0 [i915]
      <4> [110.025405]  #3: ffff88826a0c7a18 (&(&rq->lock)->rlock){?.-.}, at: i915_request_retire+0x221/0x930 [i915]
      <4> [110.025634]
      stack backtrace:
      <4> [110.025653] CPU: 0 PID: 5 Comm: kworker/0:0 Tainted: G     U            5.4.0-rc8-CI-CI_DRM_7489+ #1
      <4> [110.025675] Hardware name:  /NUC7i5BNB, BIOS BNKBL357.86A.0054.2017.1025.1822 10/25/2017
      <4> [110.025856] Workqueue: events engine_retire [i915]
      <4> [110.025872] Call Trace:
      <4> [110.025891]  dump_stack+0x71/0x9b
      <4> [110.025907]  mark_lock+0x49a/0x500
      <4> [110.025926]  ? print_shortest_lock_dependencies+0x200/0x200
      <4> [110.025946]  mark_held_locks+0x49/0x70
      <4> [110.025962]  ? _raw_spin_unlock_irq+0x24/0x50
      <4> [110.025978]  lockdep_hardirqs_on+0xa2/0x1c0
      <4> [110.025995]  _raw_spin_unlock_irq+0x24/0x50
      <4> [110.026171]  virtual_context_destroy+0xc5/0x2e0 [i915]
      <4> [110.026376]  __active_retire+0xb4/0x290 [i915]
      <4> [110.026396]  dma_fence_signal_locked+0x9e/0x1b0
      <4> [110.026613]  i915_request_retire+0x451/0x930 [i915]
      <4> [110.026766]  retire_requests+0x4d/0x60 [i915]
      <4> [110.026919]  engine_retire+0x63/0xe0 [i915]
      
      Fixes: b1e3177b ("drm/i915: Coordinate i915_active with its own mutex")
      Fixes: 6d06779e ("drm/i915: Load balancing across a virtual engine")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191205145934.663183-1-chris@chris-wilson.co.uk
      6f7ac828
    • Chris Wilson's avatar
      drm/i915/gem: Reinitialise the local list before repeating · 5c4fe63a
      Chris Wilson authored
      As we may start the loop again, we require our local list of i915_vma
      we've processed to be reinitialised.
      
      Fixes: aa5e4453 ("drm/i915/gem: Try to flush pending unbind events")
      Closes: https://gitlab.freedesktop.org/drm/intel/issues/731Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarAndi Shyti <andi.shyti@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191205132912.606868-1-chris@chris-wilson.co.uk
      5c4fe63a