All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm/i915: Lock signaler timeline while navigating
@ 2019-09-17  7:43 Chris Wilson
  2019-09-17  8:15 ` ✓ Fi.CI.BAT: success for " Patchwork
                   ` (6 more replies)
  0 siblings, 7 replies; 14+ messages in thread
From: Chris Wilson @ 2019-09-17  7:43 UTC (permalink / raw)
  To: intel-gfx

As we need to take a walk back along the signaler timeline to find the
fence before upon which we want to wait, we need to lock that timeline
to prevent it being modified as we walk. Similarly, we also need to
acquire a reference to the earlier fence while it still exists!

Though we lack the correct locking today, we are saved by the
overarching struct_mutex -- but that protection is being removed.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/i915_request.c | 30 +++++++++++++++++++++++------
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index f12358150097..452ad7a8ff0c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -767,16 +767,34 @@ i915_request_create(struct intel_context *ce)
 static int
 i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
 {
-	if (list_is_first(&signal->link, &signal->timeline->requests))
+	struct intel_timeline *tl = signal->timeline;
+	struct dma_fence *fence;
+	int err;
+
+	if (list_is_first(&signal->link, &tl->requests))
 		return 0;
 
-	signal = list_prev_entry(signal, link);
-	if (intel_timeline_sync_is_later(rq->timeline, &signal->fence))
+	if (mutex_lock_interruptible_nested(&tl->mutex, SINGLE_DEPTH_NESTING))
+		return -EINTR;
+
+	if (list_is_first(&signal->link, &tl->requests)) {
+		fence = NULL;
+	} else {
+		signal = list_prev_entry(signal, link);
+		fence = dma_fence_get_rcu(&signal->fence);
+	}
+	mutex_unlock(&tl->mutex);
+	if (!fence)
 		return 0;
 
-	return i915_sw_fence_await_dma_fence(&rq->submit,
-					     &signal->fence, 0,
-					     I915_FENCE_GFP);
+	err = 0;
+	if (!intel_timeline_sync_is_later(rq->timeline, fence))
+		err = i915_sw_fence_await_dma_fence(&rq->submit,
+						    fence, 0,
+						    I915_FENCE_GFP);
+	dma_fence_put(fence);
+
+	return err;
 }
 
 static intel_engine_mask_t
-- 
2.23.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* ✓ Fi.CI.BAT: success for drm/i915: Lock signaler timeline while navigating
  2019-09-17  7:43 [PATCH] drm/i915: Lock signaler timeline while navigating Chris Wilson
@ 2019-09-17  8:15 ` Patchwork
  2019-09-17 11:44 ` ✓ Fi.CI.IGT: " Patchwork
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2019-09-17  8:15 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Lock signaler timeline while navigating
URL   : https://patchwork.freedesktop.org/series/66799/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6906 -> Patchwork_14426
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/

Known issues
------------

  Here are the changes found in Patchwork_14426 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_mmap_gtt@basic-write:
    - fi-icl-u3:          [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +2 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/fi-icl-u3/igt@gem_mmap_gtt@basic-write.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/fi-icl-u3/igt@gem_mmap_gtt@basic-write.html

  * igt@i915_module_load@reload:
    - fi-blb-e6850:       [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/fi-blb-e6850/igt@i915_module_load@reload.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/fi-blb-e6850/igt@i915_module_load@reload.html

  * igt@i915_selftest@live_execlists:
    - fi-skl-gvtdvm:      [PASS][5] -> [DMESG-FAIL][6] ([fdo#111108])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html

  
#### Possible fixes ####

  * igt@gem_ctx_create@basic-files:
    - fi-bxt-dsi:         [INCOMPLETE][7] ([fdo#103927]) -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/fi-bxt-dsi/igt@gem_ctx_create@basic-files.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/fi-bxt-dsi/igt@gem_ctx_create@basic-files.html

  * igt@gem_exec_fence@nb-await-default:
    - {fi-tgl-u}:         [FAIL][9] ([fdo#111562] / [fdo#111597]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/fi-tgl-u/igt@gem_exec_fence@nb-await-default.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/fi-tgl-u/igt@gem_exec_fence@nb-await-default.html

  * igt@gem_mmap_gtt@basic-read-write:
    - fi-icl-u3:          [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/fi-icl-u3/igt@gem_mmap_gtt@basic-read-write.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/fi-icl-u3/igt@gem_mmap_gtt@basic-read-write.html

  * igt@i915_module_load@reload:
    - {fi-icl-u4}:        [DMESG-WARN][13] ([fdo#105602]) -> [PASS][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/fi-icl-u4/igt@i915_module_load@reload.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/fi-icl-u4/igt@i915_module_load@reload.html
    - fi-icl-u3:          [DMESG-WARN][15] ([fdo#107724] / [fdo#111214]) -> [PASS][16]
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/fi-icl-u3/igt@i915_module_load@reload.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/fi-icl-u3/igt@i915_module_load@reload.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
  [fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
  [fdo#106350]: https://bugs.freedesktop.org/show_bug.cgi?id=106350
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111108]: https://bugs.freedesktop.org/show_bug.cgi?id=111108
  [fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
  [fdo#111562]: https://bugs.freedesktop.org/show_bug.cgi?id=111562
  [fdo#111597]: https://bugs.freedesktop.org/show_bug.cgi?id=111597


Participating hosts (55 -> 47)
------------------------------

  Missing    (8): fi-ilk-m540 fi-hsw-4200u fi-skl-6770hq fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6906 -> Patchwork_14426

  CI-20190529: 20190529
  CI_DRM_6906: 72e400c2b824ab108907631fcf896d3d2020e7d5 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5186: 0008b3e1b2cf7a73b1e995031c9a73fc97b35aad @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14426: e998f828be52c9860960a1e0bf01536d6670a293 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

e998f828be52 drm/i915: Lock signaler timeline while navigating

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* ✓ Fi.CI.IGT: success for drm/i915: Lock signaler timeline while navigating
  2019-09-17  7:43 [PATCH] drm/i915: Lock signaler timeline while navigating Chris Wilson
  2019-09-17  8:15 ` ✓ Fi.CI.BAT: success for " Patchwork
@ 2019-09-17 11:44 ` Patchwork
  2019-09-17 14:51 ` [PATCH] " Tvrtko Ursulin
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2019-09-17 11:44 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Lock signaler timeline while navigating
URL   : https://patchwork.freedesktop.org/series/66799/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6906_full -> Patchwork_14426_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

Known issues
------------

  Here are the changes found in Patchwork_14426_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_schedule@preempt-contexts-bsd:
    - shard-iclb:         [PASS][1] -> [SKIP][2] ([fdo#111325]) +1 similar issue
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb7/igt@gem_exec_schedule@preempt-contexts-bsd.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb2/igt@gem_exec_schedule@preempt-contexts-bsd.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup:
    - shard-apl:          [PASS][3] -> [INCOMPLETE][4] ([fdo#103927]) +2 similar issues
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-apl3/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-apl2/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup.html

  * igt@i915_pm_rc6_residency@rc6-accuracy:
    - shard-snb:          [PASS][5] -> [SKIP][6] ([fdo#109271])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-snb6/igt@i915_pm_rc6_residency@rc6-accuracy.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-snb6/igt@i915_pm_rc6_residency@rc6-accuracy.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
    - shard-apl:          [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +6 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-apl6/igt@i915_suspend@fence-restore-tiled2untiled.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-apl3/igt@i915_suspend@fence-restore-tiled2untiled.html

  * igt@kms_cursor_crc@pipe-c-cursor-size-change:
    - shard-skl:          [PASS][9] -> [FAIL][10] ([fdo#103232])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl9/igt@kms_cursor_crc@pipe-c-cursor-size-change.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-skl10/igt@kms_cursor_crc@pipe-c-cursor-size-change.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible:
    - shard-skl:          [PASS][11] -> [FAIL][12] ([fdo#100368])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl5/igt@kms_flip@plain-flip-fb-recreate-interruptible.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-skl9/igt@kms_flip@plain-flip-fb-recreate-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite:
    - shard-iclb:         [PASS][13] -> [FAIL][14] ([fdo#103167]) +4 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb2/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb5/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [PASS][15] -> [FAIL][16] ([fdo#108145] / [fdo#110403])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl8/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-skl10/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
    - shard-iclb:         [PASS][17] -> [FAIL][18] ([fdo#103166])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb5/igt@kms_plane_lowres@pipe-a-tiling-x.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb7/igt@kms_plane_lowres@pipe-a-tiling-x.html

  * igt@kms_psr@psr2_primary_mmap_cpu:
    - shard-iclb:         [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar issues
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb3/igt@kms_psr@psr2_primary_mmap_cpu.html

  * igt@kms_setmode@basic:
    - shard-skl:          [PASS][21] -> [FAIL][22] ([fdo#99912])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl1/igt@kms_setmode@basic.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-skl2/igt@kms_setmode@basic.html
    - shard-kbl:          [PASS][23] -> [FAIL][24] ([fdo#99912])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-kbl2/igt@kms_setmode@basic.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-kbl2/igt@kms_setmode@basic.html

  * igt@perf_pmu@busy-double-start-vecs0:
    - shard-skl:          [PASS][25] -> [FAIL][26] ([fdo#111438])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl10/igt@perf_pmu@busy-double-start-vecs0.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-skl5/igt@perf_pmu@busy-double-start-vecs0.html

  * igt@prime_vgem@fence-wait-bsd2:
    - shard-iclb:         [PASS][27] -> [SKIP][28] ([fdo#109276]) +12 similar issues
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb4/igt@prime_vgem@fence-wait-bsd2.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb6/igt@prime_vgem@fence-wait-bsd2.html

  
#### Possible fixes ####

  * igt@gem_exec_schedule@preempt-contexts-bsd2:
    - shard-iclb:         [SKIP][29] ([fdo#109276]) -> [PASS][30] +12 similar issues
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb7/igt@gem_exec_schedule@preempt-contexts-bsd2.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb1/igt@gem_exec_schedule@preempt-contexts-bsd2.html

  * igt@gem_exec_schedule@wide-bsd:
    - shard-iclb:         [SKIP][31] ([fdo#111325]) -> [PASS][32] +2 similar issues
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb2/igt@gem_exec_schedule@wide-bsd.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb5/igt@gem_exec_schedule@wide-bsd.html

  * igt@gem_softpin@noreloc-s3:
    - shard-skl:          [INCOMPLETE][33] ([fdo#104108]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl2/igt@gem_softpin@noreloc-s3.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-skl9/igt@gem_softpin@noreloc-s3.html

  * igt@i915_suspend@sysfs-reader:
    - shard-apl:          [DMESG-WARN][35] ([fdo#108566]) -> [PASS][36] +4 similar issues
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-apl2/igt@i915_suspend@sysfs-reader.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-apl7/igt@i915_suspend@sysfs-reader.html

  * igt@kms_cursor_crc@pipe-b-cursor-suspend:
    - shard-snb:          [INCOMPLETE][37] ([fdo#105411]) -> [PASS][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-snb1/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-snb1/igt@kms_cursor_crc@pipe-b-cursor-suspend.html

  * igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled:
    - shard-skl:          [FAIL][39] ([fdo#103184] / [fdo#103232] / [fdo#108472]) -> [PASS][40]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl8/igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-skl10/igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
    - shard-skl:          [FAIL][41] ([fdo#105363]) -> [PASS][42]
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl7/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-skl3/igt@kms_flip@flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@plain-flip-ts-check:
    - shard-glk:          [FAIL][43] ([fdo#100368]) -> [PASS][44]
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-glk7/igt@kms_flip@plain-flip-ts-check.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-glk3/igt@kms_flip@plain-flip-ts-check.html

  * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
    - shard-iclb:         [FAIL][45] ([fdo#103167]) -> [PASS][46] +3 similar issues
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb4/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb8/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
    - shard-skl:          [FAIL][47] ([fdo#108145]) -> [PASS][48]
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl9/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-skl8/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html

  * igt@kms_psr@psr2_cursor_render:
    - shard-iclb:         [SKIP][49] ([fdo#109441]) -> [PASS][50] +2 similar issues
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb1/igt@kms_psr@psr2_cursor_render.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb2/igt@kms_psr@psr2_cursor_render.html

  
#### Warnings ####

  * igt@gem_mocs_settings@mocs-rc6-bsd2:
    - shard-iclb:         [FAIL][51] ([fdo#111330]) -> [SKIP][52] ([fdo#109276])
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb2/igt@gem_mocs_settings@mocs-rc6-bsd2.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-iclb3/igt@gem_mocs_settings@mocs-rc6-bsd2.html

  * igt@i915_suspend@fence-restore-untiled:
    - shard-apl:          [DMESG-WARN][53] ([fdo#108566]) -> [INCOMPLETE][54] ([fdo#103927])
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-apl7/igt@i915_suspend@fence-restore-untiled.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/shard-apl1/igt@i915_suspend@fence-restore-untiled.html

  
  [fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103184]: https://bugs.freedesktop.org/show_bug.cgi?id=103184
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
  [fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#108472]: https://bugs.freedesktop.org/show_bug.cgi?id=108472
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#110403]: https://bugs.freedesktop.org/show_bug.cgi?id=110403
  [fdo#111325]: https://bugs.freedesktop.org/show_bug.cgi?id=111325
  [fdo#111330]: https://bugs.freedesktop.org/show_bug.cgi?id=111330
  [fdo#111438]: https://bugs.freedesktop.org/show_bug.cgi?id=111438
  [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912


Participating hosts (9 -> 10)
------------------------------

  Additional (1): pig-hsw-4770r 


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6906 -> Patchwork_14426

  CI-20190529: 20190529
  CI_DRM_6906: 72e400c2b824ab108907631fcf896d3d2020e7d5 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5186: 0008b3e1b2cf7a73b1e995031c9a73fc97b35aad @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14426: e998f828be52c9860960a1e0bf01536d6670a293 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14426/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] drm/i915: Lock signaler timeline while navigating
  2019-09-17  7:43 [PATCH] drm/i915: Lock signaler timeline while navigating Chris Wilson
  2019-09-17  8:15 ` ✓ Fi.CI.BAT: success for " Patchwork
  2019-09-17 11:44 ` ✓ Fi.CI.IGT: " Patchwork
@ 2019-09-17 14:51 ` Tvrtko Ursulin
  2019-09-17 15:04   ` Chris Wilson
  2019-09-17 15:09 ` [PATCH v2] " Chris Wilson
                   ` (3 subsequent siblings)
  6 siblings, 1 reply; 14+ messages in thread
From: Tvrtko Ursulin @ 2019-09-17 14:51 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx


On 17/09/2019 08:43, Chris Wilson wrote:
> As we need to take a walk back along the signaler timeline to find the
> fence before upon which we want to wait, we need to lock that timeline
> to prevent it being modified as we walk. Similarly, we also need to
> acquire a reference to the earlier fence while it still exists!
> 
> Though we lack the correct locking today, we are saved by the
> overarching struct_mutex -- but that protection is being removed.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>   drivers/gpu/drm/i915/i915_request.c | 30 +++++++++++++++++++++++------
>   1 file changed, 24 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> index f12358150097..452ad7a8ff0c 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -767,16 +767,34 @@ i915_request_create(struct intel_context *ce)
>   static int
>   i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
>   {
> -	if (list_is_first(&signal->link, &signal->timeline->requests))
> +	struct intel_timeline *tl = signal->timeline;
> +	struct dma_fence *fence;
> +	int err;
> +
> +	if (list_is_first(&signal->link, &tl->requests))
>   		return 0;
>   
> -	signal = list_prev_entry(signal, link);
> -	if (intel_timeline_sync_is_later(rq->timeline, &signal->fence))
> +	if (mutex_lock_interruptible_nested(&tl->mutex, SINGLE_DEPTH_NESTING))

We are getting more and more these nested ones and it will become 
unmanageable to remember which ones, why and on what paths. Perhaps we 
need a comment next to the member in the structure definition?

> +		return -EINTR;
> +
> +	if (list_is_first(&signal->link, &tl->requests)) {
> +		fence = NULL;
> +	} else {
> +		signal = list_prev_entry(signal, link);
> +		fence = dma_fence_get_rcu(&signal->fence);
> +	}
> +	mutex_unlock(&tl->mutex);
> +	if (!fence)

Can it be no fence when it was obtained under the mutex?

>   		return 0;
>   
> -	return i915_sw_fence_await_dma_fence(&rq->submit,
> -					     &signal->fence, 0,
> -					     I915_FENCE_GFP);
> +	err = 0;
> +	if (!intel_timeline_sync_is_later(rq->timeline, fence))
> +		err = i915_sw_fence_await_dma_fence(&rq->submit,
> +						    fence, 0,
> +						    I915_FENCE_GFP);
> +	dma_fence_put(fence);
> +
> +	return err;
>   }
>   
>   static intel_engine_mask_t
> 

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] drm/i915: Lock signaler timeline while navigating
  2019-09-17 14:51 ` [PATCH] " Tvrtko Ursulin
@ 2019-09-17 15:04   ` Chris Wilson
  2019-09-17 15:22     ` Tvrtko Ursulin
  0 siblings, 1 reply; 14+ messages in thread
From: Chris Wilson @ 2019-09-17 15:04 UTC (permalink / raw)
  To: Tvrtko Ursulin, intel-gfx

Quoting Tvrtko Ursulin (2019-09-17 15:51:45)
> 
> On 17/09/2019 08:43, Chris Wilson wrote:
> > As we need to take a walk back along the signaler timeline to find the
> > fence before upon which we want to wait, we need to lock that timeline
> > to prevent it being modified as we walk. Similarly, we also need to
> > acquire a reference to the earlier fence while it still exists!
> > 
> > Though we lack the correct locking today, we are saved by the
> > overarching struct_mutex -- but that protection is being removed.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> >   drivers/gpu/drm/i915/i915_request.c | 30 +++++++++++++++++++++++------
> >   1 file changed, 24 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> > index f12358150097..452ad7a8ff0c 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -767,16 +767,34 @@ i915_request_create(struct intel_context *ce)
> >   static int
> >   i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
> >   {
> > -     if (list_is_first(&signal->link, &signal->timeline->requests))
> > +     struct intel_timeline *tl = signal->timeline;
> > +     struct dma_fence *fence;
> > +     int err;
> > +
> > +     if (list_is_first(&signal->link, &tl->requests))
> >               return 0;
> >   
> > -     signal = list_prev_entry(signal, link);
> > -     if (intel_timeline_sync_is_later(rq->timeline, &signal->fence))
> > +     if (mutex_lock_interruptible_nested(&tl->mutex, SINGLE_DEPTH_NESTING))
> 
> We are getting more and more these nested ones and it will become 
> unmanageable to remember which ones, why and on what paths. Perhaps we 
> need a comment next to the member in the structure definition?

The timeline mutex is held for request construction and retire; entry
and exit of the timeline->requests. Since we have a request, it should
be holding its rq->timeline->mutex; is that what you wish documented?

Similarly that signal->timeline != rq->timeline.

GEM_BUG_ON(signal->timeline == rq->timeline);
lockdep_assert_held(&rq->timeline->mutex);

> > +             return -EINTR;
> > +
> > +     if (list_is_first(&signal->link, &tl->requests)) {
> > +             fence = NULL;
> > +     } else {
> > +             signal = list_prev_entry(signal, link);
> > +             fence = dma_fence_get_rcu(&signal->fence);
> > +     }
> > +     mutex_unlock(&tl->mutex);
> > +     if (!fence)
> 
> Can it be no fence when it was obtained under the mutex?

Yes. The previous fence may have been retired and so removed from the
tl->requests before we acquire the mutex. It should not be freed while
it is still in the list, i.e. dma_fence_get_rcu() should never return
NULL.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH v2] drm/i915: Lock signaler timeline while navigating
  2019-09-17  7:43 [PATCH] drm/i915: Lock signaler timeline while navigating Chris Wilson
                   ` (2 preceding siblings ...)
  2019-09-17 14:51 ` [PATCH] " Tvrtko Ursulin
@ 2019-09-17 15:09 ` Chris Wilson
  2019-09-17 15:20   ` Tvrtko Ursulin
  2019-09-17 15:39 ` [PATCH v3] " Chris Wilson
                   ` (2 subsequent siblings)
  6 siblings, 1 reply; 14+ messages in thread
From: Chris Wilson @ 2019-09-17 15:09 UTC (permalink / raw)
  To: intel-gfx

As we need to take a walk back along the signaler timeline to find the
fence before upon which we want to wait, we need to lock that timeline
to prevent it being modified as we walk. Similarly, we also need to
acquire a reference to the earlier fence while it still exists!

Though we lack the correct locking today, we are saved by the
overarching struct_mutex -- but that protection is being removed.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
---
Add the lockdep assert and GEM_BUG_ON to note the overlapping timelines.
---
 drivers/gpu/drm/i915/i915_request.c | 31 +++++++++++++++++++++++------
 1 file changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index f12358150097..3966b330b5de 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -767,16 +767,35 @@ i915_request_create(struct intel_context *ce)
 static int
 i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
 {
-	if (list_is_first(&signal->link, &signal->timeline->requests))
+	struct intel_timeline *tl = signal->timeline;
+	struct dma_fence *fence;
+	int err;
+
+	lockdep_assert_held(&rq->timeline->mutex);
+	GEM_BUG_ON(rq->timeline == signal->timeline);
+
+	if (list_is_first(&signal->link, &tl->requests))
 		return 0;
 
-	signal = list_prev_entry(signal, link);
-	if (intel_timeline_sync_is_later(rq->timeline, &signal->fence))
+	if (mutex_lock_interruptible_nested(&tl->mutex, SINGLE_DEPTH_NESTING))
+		return -EINTR;
+
+	fence = NULL;
+	if (!list_is_first(&signal->link, &tl->requests))
+		fence = dma_fence_get(&list_prev_entry(signal, link)->fence);
+
+	mutex_unlock(&tl->mutex);
+	if (!fence)
 		return 0;
 
-	return i915_sw_fence_await_dma_fence(&rq->submit,
-					     &signal->fence, 0,
-					     I915_FENCE_GFP);
+	err = 0;
+	if (!intel_timeline_sync_is_later(rq->timeline, fence))
+		err = i915_sw_fence_await_dma_fence(&rq->submit,
+						    fence, 0,
+						    I915_FENCE_GFP);
+	dma_fence_put(fence);
+
+	return err;
 }
 
 static intel_engine_mask_t
-- 
2.23.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH v2] drm/i915: Lock signaler timeline while navigating
  2019-09-17 15:09 ` [PATCH v2] " Chris Wilson
@ 2019-09-17 15:20   ` Tvrtko Ursulin
  0 siblings, 0 replies; 14+ messages in thread
From: Tvrtko Ursulin @ 2019-09-17 15:20 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx


On 17/09/2019 16:09, Chris Wilson wrote:
> As we need to take a walk back along the signaler timeline to find the
> fence before upon which we want to wait, we need to lock that timeline
> to prevent it being modified as we walk. Similarly, we also need to
> acquire a reference to the earlier fence while it still exists!
> 
> Though we lack the correct locking today, we are saved by the
> overarching struct_mutex -- but that protection is being removed.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> ---
> Add the lockdep assert and GEM_BUG_ON to note the overlapping timelines.
> ---
>   drivers/gpu/drm/i915/i915_request.c | 31 +++++++++++++++++++++++------
>   1 file changed, 25 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> index f12358150097..3966b330b5de 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -767,16 +767,35 @@ i915_request_create(struct intel_context *ce)
>   static int
>   i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
>   {
> -	if (list_is_first(&signal->link, &signal->timeline->requests))
> +	struct intel_timeline *tl = signal->timeline;
> +	struct dma_fence *fence;
> +	int err;
> +
> +	lockdep_assert_held(&rq->timeline->mutex);
> +	GEM_BUG_ON(rq->timeline == signal->timeline);
> +
> +	if (list_is_first(&signal->link, &tl->requests))
>   		return 0;
>   
> -	signal = list_prev_entry(signal, link);
> -	if (intel_timeline_sync_is_later(rq->timeline, &signal->fence))
> +	if (mutex_lock_interruptible_nested(&tl->mutex, SINGLE_DEPTH_NESTING))
> +		return -EINTR;
> +
> +	fence = NULL;
> +	if (!list_is_first(&signal->link, &tl->requests))
> +		fence = dma_fence_get(&list_prev_entry(signal, link)->fence);
> +
> +	mutex_unlock(&tl->mutex);
> +	if (!fence)
>   		return 0;
>   
> -	return i915_sw_fence_await_dma_fence(&rq->submit,
> -					     &signal->fence, 0,
> -					     I915_FENCE_GFP);
> +	err = 0;
> +	if (!intel_timeline_sync_is_later(rq->timeline, fence))
> +		err = i915_sw_fence_await_dma_fence(&rq->submit,
> +						    fence, 0,
> +						    I915_FENCE_GFP);
> +	dma_fence_put(fence);
> +
> +	return err;
>   }
>   
>   static intel_engine_mask_t
> 

Yes the asserts make it obvious now why the nested annotation is needed.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] drm/i915: Lock signaler timeline while navigating
  2019-09-17 15:04   ` Chris Wilson
@ 2019-09-17 15:22     ` Tvrtko Ursulin
  0 siblings, 0 replies; 14+ messages in thread
From: Tvrtko Ursulin @ 2019-09-17 15:22 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx


On 17/09/2019 16:04, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-09-17 15:51:45)
>>
>> On 17/09/2019 08:43, Chris Wilson wrote:
>>> As we need to take a walk back along the signaler timeline to find the
>>> fence before upon which we want to wait, we need to lock that timeline
>>> to prevent it being modified as we walk. Similarly, we also need to
>>> acquire a reference to the earlier fence while it still exists!
>>>
>>> Though we lack the correct locking today, we are saved by the
>>> overarching struct_mutex -- but that protection is being removed.
>>>
>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> ---
>>>    drivers/gpu/drm/i915/i915_request.c | 30 +++++++++++++++++++++++------
>>>    1 file changed, 24 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
>>> index f12358150097..452ad7a8ff0c 100644
>>> --- a/drivers/gpu/drm/i915/i915_request.c
>>> +++ b/drivers/gpu/drm/i915/i915_request.c
>>> @@ -767,16 +767,34 @@ i915_request_create(struct intel_context *ce)
>>>    static int
>>>    i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
>>>    {
>>> -     if (list_is_first(&signal->link, &signal->timeline->requests))
>>> +     struct intel_timeline *tl = signal->timeline;
>>> +     struct dma_fence *fence;
>>> +     int err;
>>> +
>>> +     if (list_is_first(&signal->link, &tl->requests))
>>>                return 0;
>>>    
>>> -     signal = list_prev_entry(signal, link);
>>> -     if (intel_timeline_sync_is_later(rq->timeline, &signal->fence))
>>> +     if (mutex_lock_interruptible_nested(&tl->mutex, SINGLE_DEPTH_NESTING))
>>
>> We are getting more and more these nested ones and it will become
>> unmanageable to remember which ones, why and on what paths. Perhaps we
>> need a comment next to the member in the structure definition?
> 
> The timeline mutex is held for request construction and retire; entry
> and exit of the timeline->requests. Since we have a request, it should
> be holding its rq->timeline->mutex; is that what you wish documented?
> 
> Similarly that signal->timeline != rq->timeline.
> 
> GEM_BUG_ON(signal->timeline == rq->timeline);
> lockdep_assert_held(&rq->timeline->mutex);

Yeah that helps.

>>> +             return -EINTR;
>>> +
>>> +     if (list_is_first(&signal->link, &tl->requests)) {
>>> +             fence = NULL;
>>> +     } else {
>>> +             signal = list_prev_entry(signal, link);
>>> +             fence = dma_fence_get_rcu(&signal->fence);
>>> +     }
>>> +     mutex_unlock(&tl->mutex);
>>> +     if (!fence)
>>
>> Can it be no fence when it was obtained under the mutex?
> 
> Yes. The previous fence may have been retired and so removed from the
> tl->requests before we acquire the mutex. It should not be freed while
> it is still in the list, i.e. dma_fence_get_rcu() should never return
> NULL.

I did not worry about the list_is_first check, just about 
dma_fence_get_rcu. At least I'm happy that one is safe and v2 is even 
better in this respect.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH v3] drm/i915: Lock signaler timeline while navigating
  2019-09-17  7:43 [PATCH] drm/i915: Lock signaler timeline while navigating Chris Wilson
                   ` (3 preceding siblings ...)
  2019-09-17 15:09 ` [PATCH v2] " Chris Wilson
@ 2019-09-17 15:39 ` Chris Wilson
  2019-09-18 13:38   ` Tvrtko Ursulin
  2019-09-17 17:40 ` ✓ Fi.CI.BAT: success for drm/i915: Lock signaler timeline while navigating (rev3) Patchwork
  2019-09-18  7:36 ` ✓ Fi.CI.IGT: " Patchwork
  6 siblings, 1 reply; 14+ messages in thread
From: Chris Wilson @ 2019-09-17 15:39 UTC (permalink / raw)
  To: intel-gfx

As we need to take a walk back along the signaler timeline to find the
fence before upon which we want to wait, we need to lock that timeline
to prevent it being modified as we walk. Similarly, we also need to
acquire a reference to the earlier fence while it still exists!

Though we lack the correct locking today, we are saved by the
overarching struct_mutex -- but that protection is being removed.

v2: Tvrtko made me realise I was being lax and using annotations to
ignore the AB-BA deadlock from the timeline overlap. As it would be
possible to construct a second request that was using a semaphore from the
same timeline as ourselves, we could quite easily end up in a situation
where we deadlocked in our mutex waits. Avoid that by using a trylock
and falling back to a normal dma-fence await if contended.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_request.c | 56 +++++++++++++++++++----------
 1 file changed, 37 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index f12358150097..4e861673fe5c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -767,16 +767,35 @@ i915_request_create(struct intel_context *ce)
 static int
 i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
 {
-	if (list_is_first(&signal->link, &signal->timeline->requests))
+	struct intel_timeline *tl = signal->timeline;
+	struct dma_fence *fence;
+	int err;
+
+	lockdep_assert_held(&rq->timeline->mutex);
+	GEM_BUG_ON(rq->timeline == signal->timeline);
+
+	if (list_is_first(&signal->link, &tl->requests))
 		return 0;
 
-	signal = list_prev_entry(signal, link);
-	if (intel_timeline_sync_is_later(rq->timeline, &signal->fence))
+	if (!mutex_trylock(&tl->mutex))
+		return -EBUSY;
+
+	fence = NULL;
+	if (!list_is_first(&signal->link, &tl->requests))
+		fence = dma_fence_get(&list_prev_entry(signal, link)->fence);
+
+	mutex_unlock(&tl->mutex);
+	if (!fence)
 		return 0;
 
-	return i915_sw_fence_await_dma_fence(&rq->submit,
-					     &signal->fence, 0,
-					     I915_FENCE_GFP);
+	err = 0;
+	if (!intel_timeline_sync_is_later(rq->timeline, fence))
+		err = i915_sw_fence_await_dma_fence(&rq->submit,
+						    fence, 0,
+						    I915_FENCE_GFP);
+	dma_fence_put(fence);
+
+	return err;
 }
 
 static intel_engine_mask_t
@@ -804,30 +823,24 @@ emit_semaphore_wait(struct i915_request *to,
 {
 	u32 hwsp_offset;
 	u32 *cs;
-	int err;
 
 	GEM_BUG_ON(!from->timeline->has_initial_breadcrumb);
 	GEM_BUG_ON(INTEL_GEN(to->i915) < 8);
 
 	/* Just emit the first semaphore we see as request space is limited. */
 	if (already_busywaiting(to) & from->engine->mask)
-		return i915_sw_fence_await_dma_fence(&to->submit,
-						     &from->fence, 0,
-						     I915_FENCE_GFP);
+		goto await_fence;
 
-	err = i915_request_await_start(to, from);
-	if (err < 0)
-		return err;
+	if (i915_request_await_start(to, from) < 0)
+		goto await_fence;
 
 	/* Only submit our spinner after the signaler is running! */
-	err = __i915_request_await_execution(to, from, NULL, gfp);
-	if (err)
-		return err;
+	if (__i915_request_await_execution(to, from, NULL, gfp))
+		goto await_fence;
 
 	/* We need to pin the signaler's HWSP until we are finished reading. */
-	err = intel_timeline_read_hwsp(from, to, &hwsp_offset);
-	if (err)
-		return err;
+	if (intel_timeline_read_hwsp(from, to, &hwsp_offset))
+		goto await_fence;
 
 	cs = intel_ring_begin(to, 4);
 	if (IS_ERR(cs))
@@ -853,6 +866,11 @@ emit_semaphore_wait(struct i915_request *to,
 	to->sched.semaphores |= from->engine->mask;
 	to->sched.flags |= I915_SCHED_HAS_SEMAPHORE_CHAIN;
 	return 0;
+
+await_fence:
+	return i915_sw_fence_await_dma_fence(&to->submit,
+					     &from->fence, 0,
+					     I915_FENCE_GFP);
 }
 
 static int
-- 
2.23.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* ✓ Fi.CI.BAT: success for drm/i915: Lock signaler timeline while navigating (rev3)
  2019-09-17  7:43 [PATCH] drm/i915: Lock signaler timeline while navigating Chris Wilson
                   ` (4 preceding siblings ...)
  2019-09-17 15:39 ` [PATCH v3] " Chris Wilson
@ 2019-09-17 17:40 ` Patchwork
  2019-09-18  7:36 ` ✓ Fi.CI.IGT: " Patchwork
  6 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2019-09-17 17:40 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Lock signaler timeline while navigating (rev3)
URL   : https://patchwork.freedesktop.org/series/66799/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6910 -> Patchwork_14434
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/

Known issues
------------

  Here are the changes found in Patchwork_14434 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_create@basic-files:
    - fi-icl-u2:          [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / [fdo#109100])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-icl-u2/igt@gem_ctx_create@basic-files.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/fi-icl-u2/igt@gem_ctx_create@basic-files.html

  * igt@gem_exec_suspend@basic-s3:
    - fi-blb-e6850:       [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html

  
#### Possible fixes ####

  * igt@gem_exec_fence@nb-await-default:
    - {fi-tgl-u2}:        [FAIL][5] ([fdo#111562] / [fdo#111597]) -> [PASS][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-tgl-u2/igt@gem_exec_fence@nb-await-default.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/fi-tgl-u2/igt@gem_exec_fence@nb-await-default.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
    - fi-apl-guc:         [DMESG-WARN][7] ([fdo#103558]) -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-apl-guc/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/fi-apl-guc/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html

  * igt@prime_busy@basic-wait-before-default:
    - fi-icl-u3:          [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +2 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-icl-u3/igt@prime_busy@basic-wait-before-default.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/fi-icl-u3/igt@prime_busy@basic-wait-before-default.html

  * igt@prime_vgem@basic-fence-flip:
    - fi-ilk-650:         [DMESG-WARN][11] ([fdo#106387]) -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-ilk-650/igt@prime_vgem@basic-fence-flip.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/fi-ilk-650/igt@prime_vgem@basic-fence-flip.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
  [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
  [fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111562]: https://bugs.freedesktop.org/show_bug.cgi?id=111562
  [fdo#111597]: https://bugs.freedesktop.org/show_bug.cgi?id=111597


Participating hosts (52 -> 46)
------------------------------

  Additional (1): fi-kbl-soraka 
  Missing    (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-kbl-7500u fi-icl-y fi-icl-dsi fi-bdw-samus 


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6910 -> Patchwork_14434

  CI-20190529: 20190529
  CI_DRM_6910: 4bed63ef83f108048a4fe3e3ac651ef0a32540ef @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5189: c78b9959fa4050725b16d55a5e56315884a2753d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14434: 6677a773f1ea976bf4582de153d06eb271495327 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

6677a773f1ea drm/i915: Lock signaler timeline while navigating

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* ✓ Fi.CI.IGT: success for drm/i915: Lock signaler timeline while navigating (rev3)
  2019-09-17  7:43 [PATCH] drm/i915: Lock signaler timeline while navigating Chris Wilson
                   ` (5 preceding siblings ...)
  2019-09-17 17:40 ` ✓ Fi.CI.BAT: success for drm/i915: Lock signaler timeline while navigating (rev3) Patchwork
@ 2019-09-18  7:36 ` Patchwork
  6 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2019-09-18  7:36 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Lock signaler timeline while navigating (rev3)
URL   : https://patchwork.freedesktop.org/series/66799/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6910_full -> Patchwork_14434_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

Known issues
------------

  Here are the changes found in Patchwork_14434_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_shared@exec-single-timeline-bsd:
    - shard-iclb:         [PASS][1] -> [SKIP][2] ([fdo#110841])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb8/igt@gem_ctx_shared@exec-single-timeline-bsd.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb4/igt@gem_ctx_shared@exec-single-timeline-bsd.html

  * igt@gem_exec_schedule@preempt-other-chain-bsd:
    - shard-iclb:         [PASS][3] -> [SKIP][4] ([fdo#111325]) +8 similar issues
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb3/igt@gem_exec_schedule@preempt-other-chain-bsd.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb1/igt@gem_exec_schedule@preempt-other-chain-bsd.html

  * igt@gem_softpin@noreloc-s3:
    - shard-apl:          [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +4 similar issues
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-apl6/igt@gem_softpin@noreloc-s3.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-apl3/igt@gem_softpin@noreloc-s3.html

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
    - shard-hsw:          [PASS][7] -> [FAIL][8] ([fdo#105767])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-hsw5/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-hsw6/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html

  * igt@kms_flip@flip-vs-blocking-wf-vblank:
    - shard-apl:          [PASS][9] -> [INCOMPLETE][10] ([fdo#103927]) +3 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-apl4/igt@kms_flip@flip-vs-blocking-wf-vblank.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-apl6/igt@kms_flip@flip-vs-blocking-wf-vblank.html

  * igt@kms_flip@flip-vs-expired-vblank:
    - shard-glk:          [PASS][11] -> [FAIL][12] ([fdo#105363])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-glk8/igt@kms_flip@flip-vs-expired-vblank.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-glk7/igt@kms_flip@flip-vs-expired-vblank.html

  * igt@kms_flip@flip-vs-suspend:
    - shard-skl:          [PASS][13] -> [INCOMPLETE][14] ([fdo#109507])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-skl1/igt@kms_flip@flip-vs-suspend.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-skl4/igt@kms_flip@flip-vs-suspend.html

  * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite:
    - shard-iclb:         [PASS][15] -> [FAIL][16] ([fdo#103167]) +1 similar issue
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb8/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb5/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite.html

  * igt@kms_plane_lowres@pipe-a-tiling-y:
    - shard-iclb:         [PASS][17] -> [FAIL][18] ([fdo#103166])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb7/igt@kms_plane_lowres@pipe-a-tiling-y.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb7/igt@kms_plane_lowres@pipe-a-tiling-y.html

  * igt@kms_psr@psr2_cursor_render:
    - shard-iclb:         [PASS][19] -> [SKIP][20] ([fdo#109441]) +1 similar issue
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb5/igt@kms_psr@psr2_cursor_render.html

  * igt@kms_setmode@basic:
    - shard-skl:          [PASS][21] -> [FAIL][22] ([fdo#99912])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-skl9/igt@kms_setmode@basic.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-skl10/igt@kms_setmode@basic.html
    - shard-kbl:          [PASS][23] -> [FAIL][24] ([fdo#99912])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-kbl2/igt@kms_setmode@basic.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-kbl7/igt@kms_setmode@basic.html

  * igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend:
    - shard-skl:          [PASS][25] -> [INCOMPLETE][26] ([fdo#104108])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-skl6/igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-skl7/igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend.html

  * igt@perf@blocking:
    - shard-skl:          [PASS][27] -> [FAIL][28] ([fdo#110728]) +1 similar issue
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-skl6/igt@perf@blocking.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-skl7/igt@perf@blocking.html

  * igt@prime_busy@after-bsd2:
    - shard-iclb:         [PASS][29] -> [SKIP][30] ([fdo#109276]) +18 similar issues
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb1/igt@prime_busy@after-bsd2.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb7/igt@prime_busy@after-bsd2.html

  
#### Possible fixes ####

  * igt@gem_eio@reset-stress:
    - shard-glk:          [FAIL][31] ([fdo#109661]) -> [PASS][32]
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-glk2/igt@gem_eio@reset-stress.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-glk9/igt@gem_eio@reset-stress.html

  * igt@gem_eio@unwedge-stress:
    - shard-snb:          [FAIL][33] ([fdo#109661]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-snb2/igt@gem_eio@unwedge-stress.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-snb4/igt@gem_eio@unwedge-stress.html

  * igt@gem_exec_schedule@in-order-bsd:
    - shard-iclb:         [SKIP][35] ([fdo#111325]) -> [PASS][36] +6 similar issues
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb1/igt@gem_exec_schedule@in-order-bsd.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb8/igt@gem_exec_schedule@in-order-bsd.html

  * igt@gem_exec_schedule@preempt-queue-bsd1:
    - shard-iclb:         [SKIP][37] ([fdo#109276]) -> [PASS][38] +16 similar issues
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb5/igt@gem_exec_schedule@preempt-queue-bsd1.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb2/igt@gem_exec_schedule@preempt-queue-bsd1.html

  * igt@gem_tiled_swapping@non-threaded:
    - shard-apl:          [DMESG-WARN][39] ([fdo#108686]) -> [PASS][40]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-apl3/igt@gem_tiled_swapping@non-threaded.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-apl6/igt@gem_tiled_swapping@non-threaded.html

  * igt@i915_suspend@sysfs-reader:
    - shard-apl:          [DMESG-WARN][41] ([fdo#108566]) -> [PASS][42] +7 similar issues
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-apl1/igt@i915_suspend@sysfs-reader.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-apl2/igt@i915_suspend@sysfs-reader.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
    - shard-skl:          [INCOMPLETE][43] ([fdo#110741]) -> [PASS][44]
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-skl10/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-skl5/igt@kms_cursor_crc@pipe-a-cursor-suspend.html

  * igt@kms_draw_crc@draw-method-xrgb8888-pwrite-ytiled:
    - shard-skl:          [FAIL][45] ([fdo#103184] / [fdo#103232] / [fdo#108222]) -> [PASS][46]
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-skl3/igt@kms_draw_crc@draw-method-xrgb8888-pwrite-ytiled.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-skl10/igt@kms_draw_crc@draw-method-xrgb8888-pwrite-ytiled.html

  * igt@kms_flip@flip-vs-expired-vblank:
    - shard-skl:          [FAIL][47] ([fdo#105363]) -> [PASS][48] +1 similar issue
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-skl6/igt@kms_flip@flip-vs-expired-vblank.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-skl1/igt@kms_flip@flip-vs-expired-vblank.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
    - shard-glk:          [FAIL][49] ([fdo#105363]) -> [PASS][50]
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-glk1/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-glk4/igt@kms_flip@flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
    - shard-snb:          [INCOMPLETE][51] ([fdo#105411]) -> [PASS][52]
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-snb1/igt@kms_flip@flip-vs-suspend-interruptible.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-snb1/igt@kms_flip@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render:
    - shard-iclb:         [FAIL][53] ([fdo#103167]) -> [PASS][54] +3 similar issues
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb2/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render.html

  * igt@kms_psr@psr2_cursor_blt:
    - shard-iclb:         [SKIP][55] ([fdo#109441]) -> [PASS][56] +1 similar issue
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb6/igt@kms_psr@psr2_cursor_blt.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html

  
#### Warnings ####

  * igt@gem_ctx_isolation@vcs1-nonpriv:
    - shard-iclb:         [SKIP][57] ([fdo#109276]) -> [FAIL][58] ([fdo#111329])
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb6/igt@gem_ctx_isolation@vcs1-nonpriv.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb2/igt@gem_ctx_isolation@vcs1-nonpriv.html

  * igt@gem_mocs_settings@mocs-isolation-bsd2:
    - shard-iclb:         [FAIL][59] ([fdo#111330]) -> [SKIP][60] ([fdo#109276])
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb2/igt@gem_mocs_settings@mocs-isolation-bsd2.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb5/igt@gem_mocs_settings@mocs-isolation-bsd2.html

  * igt@gem_mocs_settings@mocs-settings-bsd2:
    - shard-iclb:         [SKIP][61] ([fdo#109276]) -> [FAIL][62] ([fdo#111330])
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/shard-iclb8/igt@gem_mocs_settings@mocs-settings-bsd2.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/shard-iclb1/igt@gem_mocs_settings@mocs-settings-bsd2.html

  
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103184]: https://bugs.freedesktop.org/show_bug.cgi?id=103184
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
  [fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
  [fdo#105767]: https://bugs.freedesktop.org/show_bug.cgi?id=105767
  [fdo#108222]: https://bugs.freedesktop.org/show_bug.cgi?id=108222
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#108686]: https://bugs.freedesktop.org/show_bug.cgi?id=108686
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109507]: https://bugs.freedesktop.org/show_bug.cgi?id=109507
  [fdo#109661]: https://bugs.freedesktop.org/show_bug.cgi?id=109661
  [fdo#110728]: https://bugs.freedesktop.org/show_bug.cgi?id=110728
  [fdo#110741]: https://bugs.freedesktop.org/show_bug.cgi?id=110741
  [fdo#110841]: https://bugs.freedesktop.org/show_bug.cgi?id=110841
  [fdo#111325]: https://bugs.freedesktop.org/show_bug.cgi?id=111325
  [fdo#111329]: https://bugs.freedesktop.org/show_bug.cgi?id=111329
  [fdo#111330]: https://bugs.freedesktop.org/show_bug.cgi?id=111330
  [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912


Participating hosts (10 -> 10)
------------------------------

  No changes in participating hosts


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6910 -> Patchwork_14434

  CI-20190529: 20190529
  CI_DRM_6910: 4bed63ef83f108048a4fe3e3ac651ef0a32540ef @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5189: c78b9959fa4050725b16d55a5e56315884a2753d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14434: 6677a773f1ea976bf4582de153d06eb271495327 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3] drm/i915: Lock signaler timeline while navigating
  2019-09-17 15:39 ` [PATCH v3] " Chris Wilson
@ 2019-09-18 13:38   ` Tvrtko Ursulin
  2019-09-18 13:44     ` Chris Wilson
  0 siblings, 1 reply; 14+ messages in thread
From: Tvrtko Ursulin @ 2019-09-18 13:38 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx


On 17/09/2019 16:39, Chris Wilson wrote:
> As we need to take a walk back along the signaler timeline to find the
> fence before upon which we want to wait, we need to lock that timeline
> to prevent it being modified as we walk. Similarly, we also need to
> acquire a reference to the earlier fence while it still exists!
> 
> Though we lack the correct locking today, we are saved by the
> overarching struct_mutex -- but that protection is being removed.
> 
> v2: Tvrtko made me realise I was being lax and using annotations to
> ignore the AB-BA deadlock from the timeline overlap. As it would be
> possible to construct a second request that was using a semaphore from the
> same timeline as ourselves, we could quite easily end up in a situation
> where we deadlocked in our mutex waits. Avoid that by using a trylock
> and falling back to a normal dma-fence await if contended.

I did not figure out the exact AB-BA, but even on a more basic level 
without the deadlock, using trylock would mean false positives ie. 
falling back to software signaling with random mutex contention on the 
same timeline. From a performance perspective this sounds not end of the 
world, just unfortunate, but from the design perspective it has me 
running away scared.

I guess the AB-BA would be interdependent requests from two timelines 
where the direction of dependency switches over across two pairs of 
submissions.

> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> ---
>   drivers/gpu/drm/i915/i915_request.c | 56 +++++++++++++++++++----------
>   1 file changed, 37 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> index f12358150097..4e861673fe5c 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -767,16 +767,35 @@ i915_request_create(struct intel_context *ce)
>   static int
>   i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
>   {
> -	if (list_is_first(&signal->link, &signal->timeline->requests))
> +	struct intel_timeline *tl = signal->timeline;
> +	struct dma_fence *fence;
> +	int err;
> +
> +	lockdep_assert_held(&rq->timeline->mutex);
> +	GEM_BUG_ON(rq->timeline == signal->timeline);
> +
> +	if (list_is_first(&signal->link, &tl->requests))
>   		return 0;
>   
> -	signal = list_prev_entry(signal, link);
> -	if (intel_timeline_sync_is_later(rq->timeline, &signal->fence))
> +	if (!mutex_trylock(&tl->mutex))
> +		return -EBUSY;
> +
> +	fence = NULL;
> +	if (!list_is_first(&signal->link, &tl->requests))
> +		fence = dma_fence_get(&list_prev_entry(signal, link)->fence);
> +
> +	mutex_unlock(&tl->mutex);
> +	if (!fence)
>   		return 0;
>   
> -	return i915_sw_fence_await_dma_fence(&rq->submit,
> -					     &signal->fence, 0,
> -					     I915_FENCE_GFP);
> +	err = 0;
> +	if (!intel_timeline_sync_is_later(rq->timeline, fence))
> +		err = i915_sw_fence_await_dma_fence(&rq->submit,
> +						    fence, 0,
> +						    I915_FENCE_GFP);
> +	dma_fence_put(fence);
> +
> +	return err;
>   }
>   
>   static intel_engine_mask_t
> @@ -804,30 +823,24 @@ emit_semaphore_wait(struct i915_request *to,
>   {
>   	u32 hwsp_offset;
>   	u32 *cs;
> -	int err;
>   
>   	GEM_BUG_ON(!from->timeline->has_initial_breadcrumb);
>   	GEM_BUG_ON(INTEL_GEN(to->i915) < 8);
>   
>   	/* Just emit the first semaphore we see as request space is limited. */
>   	if (already_busywaiting(to) & from->engine->mask)
> -		return i915_sw_fence_await_dma_fence(&to->submit,
> -						     &from->fence, 0,
> -						     I915_FENCE_GFP);
> +		goto await_fence;
>   
> -	err = i915_request_await_start(to, from);
> -	if (err < 0)
> -		return err;
> +	if (i915_request_await_start(to, from) < 0)
> +		goto await_fence;

Does this need to be explicitly only on -EBUSY? Otherwise if 
i915_sw_fence_await_dma_fence fails in i915_request_await_start code 
jump to do the same i915_sw_fence_await_dma_fence.

>   
>   	/* Only submit our spinner after the signaler is running! */
> -	err = __i915_request_await_execution(to, from, NULL, gfp);
> -	if (err)
> -		return err;
> +	if (__i915_request_await_execution(to, from, NULL, gfp))
> +		goto await_fence;
>   
>   	/* We need to pin the signaler's HWSP until we are finished reading. */
> -	err = intel_timeline_read_hwsp(from, to, &hwsp_offset);
> -	if (err)
> -		return err;
> +	if (intel_timeline_read_hwsp(from, to, &hwsp_offset))
> +		goto await_fence;
>   
>   	cs = intel_ring_begin(to, 4);
>   	if (IS_ERR(cs))
> @@ -853,6 +866,11 @@ emit_semaphore_wait(struct i915_request *to,
>   	to->sched.semaphores |= from->engine->mask;
>   	to->sched.flags |= I915_SCHED_HAS_SEMAPHORE_CHAIN;
>   	return 0;
> +
> +await_fence:
> +	return i915_sw_fence_await_dma_fence(&to->submit,
> +					     &from->fence, 0,
> +					     I915_FENCE_GFP);
>   }
>   
>   static int
> 

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3] drm/i915: Lock signaler timeline while navigating
  2019-09-18 13:38   ` Tvrtko Ursulin
@ 2019-09-18 13:44     ` Chris Wilson
  2019-09-18 13:58       ` Tvrtko Ursulin
  0 siblings, 1 reply; 14+ messages in thread
From: Chris Wilson @ 2019-09-18 13:44 UTC (permalink / raw)
  To: Tvrtko Ursulin, intel-gfx

Quoting Tvrtko Ursulin (2019-09-18 14:38:06)
> 
> On 17/09/2019 16:39, Chris Wilson wrote:
> > As we need to take a walk back along the signaler timeline to find the
> > fence before upon which we want to wait, we need to lock that timeline
> > to prevent it being modified as we walk. Similarly, we also need to
> > acquire a reference to the earlier fence while it still exists!
> > 
> > Though we lack the correct locking today, we are saved by the
> > overarching struct_mutex -- but that protection is being removed.
> > 
> > v2: Tvrtko made me realise I was being lax and using annotations to
> > ignore the AB-BA deadlock from the timeline overlap. As it would be
> > possible to construct a second request that was using a semaphore from the
> > same timeline as ourselves, we could quite easily end up in a situation
> > where we deadlocked in our mutex waits. Avoid that by using a trylock
> > and falling back to a normal dma-fence await if contended.
> 
> I did not figure out the exact AB-BA, but even on a more basic level 
> without the deadlock, using trylock would mean false positives ie. 
> falling back to software signaling with random mutex contention on the 
> same timeline. From a performance perspective this sounds not end of the 
> world, just unfortunate, but from the design perspective it has me 
> running away scared.
> 
> I guess the AB-BA would be interdependent requests from two timelines 
> where the direction of dependency switches over across two pairs of 
> submissions.

Exactly.

Oh, you haven't seen the worst of it yet. This is a wonderful mess that
just keeps on getting worse as you dig in.

> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > ---
> >   drivers/gpu/drm/i915/i915_request.c | 56 +++++++++++++++++++----------
> >   1 file changed, 37 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> > index f12358150097..4e861673fe5c 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -767,16 +767,35 @@ i915_request_create(struct intel_context *ce)
> >   static int
> >   i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
> >   {
> > -     if (list_is_first(&signal->link, &signal->timeline->requests))
> > +     struct intel_timeline *tl = signal->timeline;
> > +     struct dma_fence *fence;
> > +     int err;
> > +
> > +     lockdep_assert_held(&rq->timeline->mutex);
> > +     GEM_BUG_ON(rq->timeline == signal->timeline);
> > +
> > +     if (list_is_first(&signal->link, &tl->requests))
> >               return 0;
> >   
> > -     signal = list_prev_entry(signal, link);
> > -     if (intel_timeline_sync_is_later(rq->timeline, &signal->fence))
> > +     if (!mutex_trylock(&tl->mutex))
> > +             return -EBUSY;
> > +
> > +     fence = NULL;
> > +     if (!list_is_first(&signal->link, &tl->requests))
> > +             fence = dma_fence_get(&list_prev_entry(signal, link)->fence);
> > +
> > +     mutex_unlock(&tl->mutex);
> > +     if (!fence)
> >               return 0;
> >   
> > -     return i915_sw_fence_await_dma_fence(&rq->submit,
> > -                                          &signal->fence, 0,
> > -                                          I915_FENCE_GFP);
> > +     err = 0;
> > +     if (!intel_timeline_sync_is_later(rq->timeline, fence))
> > +             err = i915_sw_fence_await_dma_fence(&rq->submit,
> > +                                                 fence, 0,
> > +                                                 I915_FENCE_GFP);
> > +     dma_fence_put(fence);
> > +
> > +     return err;
> >   }
> >   
> >   static intel_engine_mask_t
> > @@ -804,30 +823,24 @@ emit_semaphore_wait(struct i915_request *to,
> >   {
> >       u32 hwsp_offset;
> >       u32 *cs;
> > -     int err;
> >   
> >       GEM_BUG_ON(!from->timeline->has_initial_breadcrumb);
> >       GEM_BUG_ON(INTEL_GEN(to->i915) < 8);
> >   
> >       /* Just emit the first semaphore we see as request space is limited. */
> >       if (already_busywaiting(to) & from->engine->mask)
> > -             return i915_sw_fence_await_dma_fence(&to->submit,
> > -                                                  &from->fence, 0,
> > -                                                  I915_FENCE_GFP);
> > +             goto await_fence;
> >   
> > -     err = i915_request_await_start(to, from);
> > -     if (err < 0)
> > -             return err;
> > +     if (i915_request_await_start(to, from) < 0)
> > +             goto await_fence;
> 
> Does this need to be explicitly only on -EBUSY? Otherwise if 
> i915_sw_fence_await_dma_fence fails in i915_request_await_start code 
> jump to do the same i915_sw_fence_await_dma_fence.

The only one that concerned me is ignoring any potential EINTR. All the
other errors are transient and so trying again with the basic await is a
valid response (imo). Not bailing out due to a pending signal though is a
trade-off between our latency and their latency. To be honest, I like
the simpler code where we just pretend we never noticed the signal
unless we block again.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v3] drm/i915: Lock signaler timeline while navigating
  2019-09-18 13:44     ` Chris Wilson
@ 2019-09-18 13:58       ` Tvrtko Ursulin
  0 siblings, 0 replies; 14+ messages in thread
From: Tvrtko Ursulin @ 2019-09-18 13:58 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx


On 18/09/2019 14:44, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-09-18 14:38:06)
>>
>> On 17/09/2019 16:39, Chris Wilson wrote:
>>> As we need to take a walk back along the signaler timeline to find the
>>> fence before upon which we want to wait, we need to lock that timeline
>>> to prevent it being modified as we walk. Similarly, we also need to
>>> acquire a reference to the earlier fence while it still exists!
>>>
>>> Though we lack the correct locking today, we are saved by the
>>> overarching struct_mutex -- but that protection is being removed.
>>>
>>> v2: Tvrtko made me realise I was being lax and using annotations to
>>> ignore the AB-BA deadlock from the timeline overlap. As it would be
>>> possible to construct a second request that was using a semaphore from the
>>> same timeline as ourselves, we could quite easily end up in a situation
>>> where we deadlocked in our mutex waits. Avoid that by using a trylock
>>> and falling back to a normal dma-fence await if contended.
>>
>> I did not figure out the exact AB-BA, but even on a more basic level
>> without the deadlock, using trylock would mean false positives ie.
>> falling back to software signaling with random mutex contention on the
>> same timeline. From a performance perspective this sounds not end of the
>> world, just unfortunate, but from the design perspective it has me
>> running away scared.
>>
>> I guess the AB-BA would be interdependent requests from two timelines
>> where the direction of dependency switches over across two pairs of
>> submissions.
> 
> Exactly.
> 
> Oh, you haven't seen the worst of it yet. This is a wonderful mess that
> just keeps on getting worse as you dig in.
> 
>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>> ---
>>>    drivers/gpu/drm/i915/i915_request.c | 56 +++++++++++++++++++----------
>>>    1 file changed, 37 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
>>> index f12358150097..4e861673fe5c 100644
>>> --- a/drivers/gpu/drm/i915/i915_request.c
>>> +++ b/drivers/gpu/drm/i915/i915_request.c
>>> @@ -767,16 +767,35 @@ i915_request_create(struct intel_context *ce)
>>>    static int
>>>    i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
>>>    {
>>> -     if (list_is_first(&signal->link, &signal->timeline->requests))
>>> +     struct intel_timeline *tl = signal->timeline;
>>> +     struct dma_fence *fence;
>>> +     int err;
>>> +
>>> +     lockdep_assert_held(&rq->timeline->mutex);
>>> +     GEM_BUG_ON(rq->timeline == signal->timeline);
>>> +
>>> +     if (list_is_first(&signal->link, &tl->requests))
>>>                return 0;
>>>    
>>> -     signal = list_prev_entry(signal, link);
>>> -     if (intel_timeline_sync_is_later(rq->timeline, &signal->fence))
>>> +     if (!mutex_trylock(&tl->mutex))
>>> +             return -EBUSY;
>>> +
>>> +     fence = NULL;
>>> +     if (!list_is_first(&signal->link, &tl->requests))
>>> +             fence = dma_fence_get(&list_prev_entry(signal, link)->fence);
>>> +
>>> +     mutex_unlock(&tl->mutex);
>>> +     if (!fence)
>>>                return 0;
>>>    
>>> -     return i915_sw_fence_await_dma_fence(&rq->submit,
>>> -                                          &signal->fence, 0,
>>> -                                          I915_FENCE_GFP);
>>> +     err = 0;
>>> +     if (!intel_timeline_sync_is_later(rq->timeline, fence))
>>> +             err = i915_sw_fence_await_dma_fence(&rq->submit,
>>> +                                                 fence, 0,
>>> +                                                 I915_FENCE_GFP);
>>> +     dma_fence_put(fence);
>>> +
>>> +     return err;
>>>    }
>>>    
>>>    static intel_engine_mask_t
>>> @@ -804,30 +823,24 @@ emit_semaphore_wait(struct i915_request *to,
>>>    {
>>>        u32 hwsp_offset;
>>>        u32 *cs;
>>> -     int err;
>>>    
>>>        GEM_BUG_ON(!from->timeline->has_initial_breadcrumb);
>>>        GEM_BUG_ON(INTEL_GEN(to->i915) < 8);
>>>    
>>>        /* Just emit the first semaphore we see as request space is limited. */
>>>        if (already_busywaiting(to) & from->engine->mask)
>>> -             return i915_sw_fence_await_dma_fence(&to->submit,
>>> -                                                  &from->fence, 0,
>>> -                                                  I915_FENCE_GFP);
>>> +             goto await_fence;
>>>    
>>> -     err = i915_request_await_start(to, from);
>>> -     if (err < 0)
>>> -             return err;
>>> +     if (i915_request_await_start(to, from) < 0)
>>> +             goto await_fence;
>>
>> Does this need to be explicitly only on -EBUSY? Otherwise if
>> i915_sw_fence_await_dma_fence fails in i915_request_await_start code
>> jump to do the same i915_sw_fence_await_dma_fence.
> 
> The only one that concerned me is ignoring any potential EINTR. All the
> other errors are transient and so trying again with the basic await is a
> valid response (imo). Not bailing out due to a pending signal though is a
> trade-off between our latency and their latency. To be honest, I like
> the simpler code where we just pretend we never noticed the signal
> unless we block again.

Okay, should be safe anyway.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2019-09-18 13:58 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-17  7:43 [PATCH] drm/i915: Lock signaler timeline while navigating Chris Wilson
2019-09-17  8:15 ` ✓ Fi.CI.BAT: success for " Patchwork
2019-09-17 11:44 ` ✓ Fi.CI.IGT: " Patchwork
2019-09-17 14:51 ` [PATCH] " Tvrtko Ursulin
2019-09-17 15:04   ` Chris Wilson
2019-09-17 15:22     ` Tvrtko Ursulin
2019-09-17 15:09 ` [PATCH v2] " Chris Wilson
2019-09-17 15:20   ` Tvrtko Ursulin
2019-09-17 15:39 ` [PATCH v3] " Chris Wilson
2019-09-18 13:38   ` Tvrtko Ursulin
2019-09-18 13:44     ` Chris Wilson
2019-09-18 13:58       ` Tvrtko Ursulin
2019-09-17 17:40 ` ✓ Fi.CI.BAT: success for drm/i915: Lock signaler timeline while navigating (rev3) Patchwork
2019-09-18  7:36 ` ✓ Fi.CI.IGT: " Patchwork

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.