https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7014/shard-kbl1/igt@i915_selftest@live_execlists.html <4> [2709.442616] ======================================================== <4> [2709.442619] WARNING: possible irq lock inversion dependency detected <4> [2709.442621] 5.4.0-rc1-CI-CI_DRM_7014+ #1 Tainted: G U <4> [2709.442623] -------------------------------------------------------- <4> [2709.442626] i915_selftest/7718 just changed the state of lock: <4> [2709.442628] ffff88825da80ea0 (&i915_request_get(rq)->submit/1){-...}, at: __i915_sw_fence_complete+0x1b2/0x250 [i915] <4> [2709.442673] but this lock took another, HARDIRQ-unsafe lock in the past: <4> [2709.442675] (&ce->pin_mutex/2){+...} <4> [2709.442676] and interrupts could create inverse lock ordering between them. <4> [2709.442681] other info that might help us debug this: <4> [2709.442683] Chain exists of: &i915_request_get(rq)->submit/1 --> &engine->active.lock --> &ce->pin_mutex/2 <4> [2709.442688] Possible interrupt unsafe locking scenario: <4> [2709.442691] CPU0 CPU1 <4> [2709.442693] ---- ---- <4> [2709.442694] lock(&ce->pin_mutex/2); <4> [2709.442696] local_irq_disable(); <4> [2709.442699] lock(&i915_request_get(rq)->submit/1); <4> [2709.442702] lock(&engine->active.lock); <4> [2709.442704] <Interrupt> <4> [2709.442705] lock(&i915_request_get(rq)->submit/1); <4> [2709.442708] *** DEADLOCK ***
The CI Bug Log issue associated to this bug has been updated. ### New filters associated * SKL KBL ICL: igt@i915_selftest@live_execlists - dmesg-warn - WARNING: possible irq lock inversion dependency detected - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5118/fi-icl-u3/igt@i915_selftest@live_execlists.html - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5119/fi-icl-u2/igt@i915_selftest@live_execlists.html - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14677/shard-iclb2/igt@i915_selftest@live_execlists.html - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14679/fi-skl-6260u/igt@i915_selftest@live_execlists.html - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14680/fi-icl-u2/igt@i915_selftest@live_execlists.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5214/fi-icl-u3/igt@i915_selftest@live_execlists.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7014/shard-kbl1/igt@i915_selftest@live_execlists.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7016/fi-icl-u4/igt@i915_selftest@live_execlists.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7018/fi-icl-u3/igt@i915_selftest@live_execlists.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7021/fi-icl-u3/igt@i915_selftest@live_execlists.html - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14685/fi-icl-u2/igt@i915_selftest@live_execlists.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7023/fi-skl-6260u/igt@i915_selftest@live_execlists.html - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14687/shard-kbl2/igt@i915_selftest@live_execlists.html - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14694/fi-skl-6260u/igt@i915_selftest@live_execlists.html
This annotation never stops giving! The silly part of it is that it's purely an annotation meant to make the lock handling easier!!!
The CI Bug Log issue associated to this bug has been updated. ### New filters associated * ICL: igt@i915_selftest@live_execlists - dmesg-warn - WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7022/fi-icl-u3/igt@i915_selftest@live_execlists.html
Chris, is this a real problem or just noise?
(In reply to Francesco Balestrieri from comment #4) > Chris, is this a real problem or just noise? No, this one is purely self-inflicted.
commit 0587152bf9a0d7ebfd7fcb401068a742027adb2a (HEAD -> drm-intel-next-queued, drm-intel/drm-intel-next-queued) Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Oct 22 13:28:45 2019 +0100 drm/i915: Drop assertion that ce->pin_mutex guards state updates The actual conditions are that we know the GPU is not accessing the context, and we hold a pin on the context image to allow CPU access. We used a fake lock on ce->pin_mutex so that we could try and use lockdep to assert that access is serialised, but the various different hardirq/softirq contexts where we need to *fake* holding the pin_mutex are causing more trouble. Still it would be nice if we did have a way to reassure ourselves that the direct update to the context image is serialised with GPU execution. In the meantime, stop lockdep complaining about false irq inversions. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111923 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191022122845.25038-1-chris@chris-wilson.co.uk
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.