All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm/i915: Recursive i915_reset_trylock() verboten
@ 2019-02-12 10:23 Chris Wilson
  2019-02-12 10:53 ` ✗ Fi.CI.SPARSE: warning for " Patchwork
                   ` (3 more replies)
  0 siblings, 4 replies; 6+ messages in thread
From: Chris Wilson @ 2019-02-12 10:23 UTC (permalink / raw)
  To: intel-gfx; +Cc: Mika Kuoppala

We cannot nest i915_reset_trylock() as the inner may wait for the
I915_RESET_BACKOFF which in turn is waiting upon sync_srcu who is
waiting for our outermost lock. As we take the reset srcu around the
fence update, we have to defer taking it in i915_gem_fault() until after
we acquire the pin on the fence to avoid nesting. This is a little ugly,
but still works. If a reset occurs between i915_vma_pin_fence() and the
second reset lock, the reset will restore the fence register back to the
pinned value before the reset lock allows us to proceed (our mmap won't
be revoked as we haven't yet marked it as being a userfault as that
requires us to hold the reset lock), so the pagefault is still
serialised with the revocation in reset.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109605
Fixes: 2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence registers across reset")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
---
 drivers/gpu/drm/i915/i915_gem.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c8c355bec091..ae1467a74a08 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1923,16 +1923,16 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
 	if (ret)
 		goto err_unpin;
 
+	ret = i915_vma_pin_fence(vma);
+	if (ret)
+		goto err_unpin;
+
 	srcu = i915_reset_trylock(dev_priv);
 	if (srcu < 0) {
 		ret = srcu;
-		goto err_unpin;
+		goto err_fence;
 	}
 
-	ret = i915_vma_pin_fence(vma);
-	if (ret)
-		goto err_reset;
-
 	/* Finally, remap it using the new GTT offset */
 	ret = remap_io_mapping(area,
 			       area->vm_start + (vma->ggtt_view.partial.offset << PAGE_SHIFT),
@@ -1940,7 +1940,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
 			       min_t(u64, vma->size, area->vm_end - area->vm_start),
 			       &ggtt->iomap);
 	if (ret)
-		goto err_fence;
+		goto err_reset;
 
 	/* Mark as being mmapped into userspace for later revocation */
 	assert_rpm_wakelock_held(dev_priv);
@@ -1950,10 +1950,10 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
 
 	i915_vma_set_ggtt_write(vma);
 
-err_fence:
-	i915_vma_unpin_fence(vma);
 err_reset:
 	i915_reset_unlock(dev_priv, srcu);
+err_fence:
+	i915_vma_unpin_fence(vma);
 err_unpin:
 	__i915_vma_unpin(vma);
 err_unlock:
-- 
2.20.1

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

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

* ✗ Fi.CI.SPARSE: warning for drm/i915: Recursive i915_reset_trylock() verboten
  2019-02-12 10:23 [PATCH] drm/i915: Recursive i915_reset_trylock() verboten Chris Wilson
@ 2019-02-12 10:53 ` Patchwork
  2019-02-12 11:12 ` [PATCH] " Mika Kuoppala
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 6+ messages in thread
From: Patchwork @ 2019-02-12 10:53 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Recursive i915_reset_trylock() verboten
URL   : https://patchwork.freedesktop.org/series/56529/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Recursive i915_reset_trylock() verboten
-O:drivers/gpu/drm/i915/i915_gem.c:1940:32: warning: expression using sizeof(void)
-O:drivers/gpu/drm/i915/i915_gem.c:1940:32: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/i915_gem.c:1940:32: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/i915_gem.c:1940:32: warning: expression using sizeof(void)

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

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

* Re: [PATCH] drm/i915: Recursive i915_reset_trylock() verboten
  2019-02-12 10:23 [PATCH] drm/i915: Recursive i915_reset_trylock() verboten Chris Wilson
  2019-02-12 10:53 ` ✗ Fi.CI.SPARSE: warning for " Patchwork
@ 2019-02-12 11:12 ` Mika Kuoppala
  2019-02-12 11:18   ` Chris Wilson
  2019-02-12 11:13 ` ✓ Fi.CI.BAT: success for " Patchwork
  2019-02-12 12:58 ` ✓ Fi.CI.IGT: " Patchwork
  3 siblings, 1 reply; 6+ messages in thread
From: Mika Kuoppala @ 2019-02-12 11:12 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx

Chris Wilson <chris@chris-wilson.co.uk> writes:

> We cannot nest i915_reset_trylock() as the inner may wait for the
> I915_RESET_BACKOFF which in turn is waiting upon sync_srcu who is
> waiting for our outermost lock. As we take the reset srcu around the
> fence update, we have to defer taking it in i915_gem_fault() until after
> we acquire the pin on the fence to avoid nesting. This is a little ugly,
> but still works. If a reset occurs between i915_vma_pin_fence() and the
> second reset lock, the reset will restore the fence register back to the
> pinned value before the reset lock allows us to proceed (our mmap won't
> be revoked as we haven't yet marked it as being a userfault as that
> requires us to hold the reset lock), so the pagefault is still
> serialised with the revocation in reset.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109605
> Fixes: 2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence registers across reset")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index c8c355bec091..ae1467a74a08 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1923,16 +1923,16 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
>  	if (ret)
>  		goto err_unpin;
>  
> +	ret = i915_vma_pin_fence(vma);
> +	if (ret)
> +		goto err_unpin;
> +

As this is obviusness slipped past us, would it
be worthwhile, in retrospect, to build a debug in
i915_reset_trylock to be vocal about it failing
to make progress?

Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>

>  	srcu = i915_reset_trylock(dev_priv);
>  	if (srcu < 0) {
>  		ret = srcu;
> -		goto err_unpin;
> +		goto err_fence;
>  	}
>  
> -	ret = i915_vma_pin_fence(vma);
> -	if (ret)
> -		goto err_reset;
> -
>  	/* Finally, remap it using the new GTT offset */
>  	ret = remap_io_mapping(area,
>  			       area->vm_start + (vma->ggtt_view.partial.offset << PAGE_SHIFT),
> @@ -1940,7 +1940,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
>  			       min_t(u64, vma->size, area->vm_end - area->vm_start),
>  			       &ggtt->iomap);
>  	if (ret)
> -		goto err_fence;
> +		goto err_reset;
>  
>  	/* Mark as being mmapped into userspace for later revocation */
>  	assert_rpm_wakelock_held(dev_priv);
> @@ -1950,10 +1950,10 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
>  
>  	i915_vma_set_ggtt_write(vma);
>  
> -err_fence:
> -	i915_vma_unpin_fence(vma);
>  err_reset:
>  	i915_reset_unlock(dev_priv, srcu);
> +err_fence:
> +	i915_vma_unpin_fence(vma);
>  err_unpin:
>  	__i915_vma_unpin(vma);
>  err_unlock:
> -- 
> 2.20.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* ✓ Fi.CI.BAT: success for drm/i915: Recursive i915_reset_trylock() verboten
  2019-02-12 10:23 [PATCH] drm/i915: Recursive i915_reset_trylock() verboten Chris Wilson
  2019-02-12 10:53 ` ✗ Fi.CI.SPARSE: warning for " Patchwork
  2019-02-12 11:12 ` [PATCH] " Mika Kuoppala
@ 2019-02-12 11:13 ` Patchwork
  2019-02-12 12:58 ` ✓ Fi.CI.IGT: " Patchwork
  3 siblings, 0 replies; 6+ messages in thread
From: Patchwork @ 2019-02-12 11:13 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Recursive i915_reset_trylock() verboten
URL   : https://patchwork.freedesktop.org/series/56529/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5591 -> Patchwork_12200
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/56529/revisions/1/mbox/

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_12200:

### IGT changes ###

#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live_workarounds:
    - {fi-icl-u2}:        PASS -> INCOMPLETE

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

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

### IGT changes ###

#### Possible fixes ####

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
    - fi-byt-clapper:     FAIL [fdo#103191] / [fdo#107362] -> PASS

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

  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362


Participating hosts (43 -> 38)
------------------------------

  Missing    (5): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-pnv-d510 fi-icl-y 


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

    * Linux: CI_DRM_5591 -> Patchwork_12200

  CI_DRM_5591: 1c5934e14f717ab09d832a7200113b02e3196e98 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4817: 08cdb644686629dcf968c6cc00e054ed5f5aae6a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12200: 50d16c9e711c71397b0c73dea2bc068e8e6947cc @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

50d16c9e711c drm/i915: Recursive i915_reset_trylock() verboten

== Logs ==

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

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

* Re: [PATCH] drm/i915: Recursive i915_reset_trylock() verboten
  2019-02-12 11:12 ` [PATCH] " Mika Kuoppala
@ 2019-02-12 11:18   ` Chris Wilson
  0 siblings, 0 replies; 6+ messages in thread
From: Chris Wilson @ 2019-02-12 11:18 UTC (permalink / raw)
  To: Mika Kuoppala, intel-gfx

Quoting Mika Kuoppala (2019-02-12 11:12:05)
> Chris Wilson <chris@chris-wilson.co.uk> writes:
> 
> > We cannot nest i915_reset_trylock() as the inner may wait for the
> > I915_RESET_BACKOFF which in turn is waiting upon sync_srcu who is
> > waiting for our outermost lock. As we take the reset srcu around the
> > fence update, we have to defer taking it in i915_gem_fault() until after
> > we acquire the pin on the fence to avoid nesting. This is a little ugly,
> > but still works. If a reset occurs between i915_vma_pin_fence() and the
> > second reset lock, the reset will restore the fence register back to the
> > pinned value before the reset lock allows us to proceed (our mmap won't
> > be revoked as we haven't yet marked it as being a userfault as that
> > requires us to hold the reset lock), so the pagefault is still
> > serialised with the revocation in reset.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109605
> > Fixes: 2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence registers across reset")
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Mika Kuoppala <mika.kuoppala@intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 16 ++++++++--------
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > index c8c355bec091..ae1467a74a08 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -1923,16 +1923,16 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
> >       if (ret)
> >               goto err_unpin;
> >  
> > +     ret = i915_vma_pin_fence(vma);
> > +     if (ret)
> > +             goto err_unpin;
> > +
> 
> As this is obviusness slipped past us, would it
> be worthwhile, in retrospect, to build a debug in
> i915_reset_trylock to be vocal about it failing
> to make progress?

If we stick a timeout in there, we just send that back to
userspace. Deadlock resolved just with a sporadic delay.
It is interruptible so it's not a complete loss, and more obvious if it
stalls? That's my thinking for not sending along the quick conversion to
wait_event_interruptible_timeout().

What I think we can do is stick a might_lock() so we get the lockdep
splat before the wait?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* ✓ Fi.CI.IGT: success for drm/i915: Recursive i915_reset_trylock() verboten
  2019-02-12 10:23 [PATCH] drm/i915: Recursive i915_reset_trylock() verboten Chris Wilson
                   ` (2 preceding siblings ...)
  2019-02-12 11:13 ` ✓ Fi.CI.BAT: success for " Patchwork
@ 2019-02-12 12:58 ` Patchwork
  3 siblings, 0 replies; 6+ messages in thread
From: Patchwork @ 2019-02-12 12:58 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Recursive i915_reset_trylock() verboten
URL   : https://patchwork.freedesktop.org/series/56529/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5591_full -> Patchwork_12200_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

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

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

### IGT changes ###

#### Issues hit ####

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
    - shard-snb:          NOTRUN -> DMESG-WARN [fdo#107956]

  * igt@kms_color@pipe-a-legacy-gamma:
    - shard-apl:          PASS -> FAIL [fdo#104782] / [fdo#108145]

  * igt@kms_cursor_crc@cursor-128x42-random:
    - shard-apl:          PASS -> FAIL [fdo#103232]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
    - shard-apl:          PASS -> FAIL [fdo#103167]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
    - shard-glk:          PASS -> FAIL [fdo#103167]

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-yf:
    - shard-glk:          PASS -> FAIL [fdo#103166]

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
    - shard-apl:          NOTRUN -> FAIL [fdo#103166]

  
#### Possible fixes ####

  * igt@gem_eio@reset-stress:
    - shard-hsw:          INCOMPLETE [fdo#103540] / [fdo#109482] -> PASS

  * igt@gem_exec_create@forked:
    - shard-apl:          INCOMPLETE [fdo#103927] -> PASS

  * igt@gem_mmap_gtt@hang:
    - shard-snb:          INCOMPLETE [fdo#105411] / [fdo#109605 ] -> PASS

  * igt@kms_busy@extended-pageflip-hang-newfb-render-c:
    - shard-glk:          DMESG-WARN [fdo#107956] -> PASS

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
    - shard-snb:          DMESG-WARN [fdo#107956] -> PASS

  * igt@kms_color@pipe-c-legacy-gamma:
    - shard-apl:          FAIL [fdo#104782] -> PASS

  * igt@kms_cursor_crc@cursor-128x128-suspend:
    - shard-apl:          FAIL [fdo#103191] / [fdo#103232] -> PASS

  * igt@kms_cursor_crc@cursor-256x256-random:
    - shard-apl:          FAIL [fdo#103232] -> PASS +2

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
    - shard-hsw:          FAIL [fdo#105767] -> PASS

  * igt@kms_cursor_legacy@pipe-b-torture-bo:
    - shard-kbl:          DMESG-WARN [fdo#107122] -> PASS

  * igt@kms_flip@flip-vs-expired-vblank:
    - shard-glk:          FAIL [fdo#102887] / [fdo#105363] -> PASS

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc:
    - shard-glk:          FAIL [fdo#103167] -> PASS +3

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
    - shard-glk:          FAIL [fdo#103166] -> PASS +3

  * igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
    - shard-apl:          FAIL [fdo#103166] -> PASS

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

  [fdo#102887]: https://bugs.freedesktop.org/show_bug.cgi?id=102887
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
  [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#107122]: https://bugs.freedesktop.org/show_bug.cgi?id=107122
  [fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109482]: https://bugs.freedesktop.org/show_bug.cgi?id=109482
  [fdo#109605 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109605 


Participating hosts (7 -> 5)
------------------------------

  Missing    (2): shard-skl shard-iclb 


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

    * Linux: CI_DRM_5591 -> Patchwork_12200

  CI_DRM_5591: 1c5934e14f717ab09d832a7200113b02e3196e98 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4817: 08cdb644686629dcf968c6cc00e054ed5f5aae6a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12200: 50d16c9e711c71397b0c73dea2bc068e8e6947cc @ 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_12200/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

end of thread, other threads:[~2019-02-12 12:58 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-02-12 10:23 [PATCH] drm/i915: Recursive i915_reset_trylock() verboten Chris Wilson
2019-02-12 10:53 ` ✗ Fi.CI.SPARSE: warning for " Patchwork
2019-02-12 11:12 ` [PATCH] " Mika Kuoppala
2019-02-12 11:18   ` Chris Wilson
2019-02-12 11:13 ` ✓ Fi.CI.BAT: success for " Patchwork
2019-02-12 12:58 ` ✓ 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.