[PATCH] drm/i915/execlists: Check for ce->state before destroy

[PATCH] drm/i915/execlists: Check for ce->state before destroy

[Chris Wilson]

As we may cancel the ce->state allocation during context pinning (but
crucially after we mark ce as operational), that means we may be asked
to destroy a nonexistent ce->state. Given the choice in handing a
complex error path on pinning, and just ignoring the lack of state in
destroy, choice the latter for simplicity.

Reported-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/intel_lrc.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 33bc914c2ef5..02ee3b12507f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1337,11 +1337,15 @@ static void execlists_schedule(struct i915_request *request,
 
 static void execlists_context_destroy(struct intel_context *ce)
 {
-	GEM_BUG_ON(!ce->state);
 	GEM_BUG_ON(ce->pin_count);
 
+	if (!ce->state)
+		return;
+
+	GEM_BUG_ON(i915_gem_object_is_active(ce->state->obj));
+
 	intel_ring_free(ce->ring);
-	__i915_gem_object_release_unless_active(ce->state->obj);
+	i915_gem_object_put(ce->state->obj);
 }
 
 static void execlists_context_unpin(struct intel_context *ce)
-- 
2.18.0.rc2

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

✓ Fi.CI.BAT: success for drm/i915/execlists: Check for ce->state before destroy

[Patchwork]

== Series Details ==

Series: drm/i915/execlists: Check for ce->state before destroy
URL   : https://patchwork.freedesktop.org/series/45249/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4368 -> Patchwork_9399 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

    ==== Issues hit ====

    igt@debugfs_test@read_all_entries:
      fi-snb-2520m:       PASS -> INCOMPLETE (fdo#103713)

    
    ==== Possible fixes ====

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
      fi-bxt-dsi:         INCOMPLETE (fdo#103927) -> PASS

    
  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927


== Participating hosts (43 -> 37) ==

  Missing    (6): fi-ilk-m540 fi-hsw-4200u fi-glk-dsi fi-bsw-cyan fi-ctg-p8600 fi-kbl-x1275 


== Build changes ==

    * Linux: CI_DRM_4368 -> Patchwork_9399

  CI_DRM_4368: f9f621dc095a8bfd2157fba018ddb542260d8daa @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4528: 6be300d405de5974b262e8b93a445be4ac618e6a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9399: 244456cee448eceaa53681ec75c55edb0ff854c7 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

244456cee448 drm/i915/execlists: Check for ce->state before destroy

== Logs ==

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

✓ Fi.CI.IGT: success for drm/i915/execlists: Check for ce->state before destroy

[Patchwork]

== Series Details ==

Series: drm/i915/execlists: Check for ce->state before destroy
URL   : https://patchwork.freedesktop.org/series/45249/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4368_full -> Patchwork_9399_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9399_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9399_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

== Possible new issues ==

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

  === IGT changes ===

    ==== Warnings ====

    igt@gem_mocs_settings@mocs-rc6-bsd1:
      shard-kbl:          SKIP -> PASS +1

    igt@pm_rc6_residency@rc6-accuracy:
      shard-kbl:          PASS -> SKIP +1

    
== Known issues ==

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

  === IGT changes ===

    ==== Issues hit ====

    igt@drv_selftest@live_gtt:
      shard-kbl:          PASS -> FAIL (fdo#105347)

    igt@drv_selftest@live_hugepages:
      shard-kbl:          PASS -> INCOMPLETE (fdo#103665)

    igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic:
      shard-glk:          PASS -> FAIL (fdo#105454, fdo#106509)

    igt@kms_setmode@basic:
      shard-apl:          PASS -> FAIL (fdo#99912)
      shard-kbl:          PASS -> FAIL (fdo#99912)

    
    ==== Possible fixes ====

    igt@drv_selftest@live_gtt:
      shard-glk:          INCOMPLETE (fdo#103359, k.org#198133) -> PASS

    igt@gem_workarounds@suspend-resume-context:
      shard-apl:          FAIL (fdo#103375) -> PASS +1

    igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
      shard-glk:          FAIL (fdo#105363) -> PASS

    igt@kms_flip@2x-plain-flip-ts-check-interruptible:
      shard-glk:          FAIL (fdo#100368) -> PASS

    igt@kms_flip@modeset-vs-vblank-race-interruptible:
      shard-glk:          FAIL (fdo#103060) -> PASS

    igt@kms_flip_tiling@flip-x-tiled:
      shard-glk:          FAIL (fdo#104724, fdo#103822) -> PASS +1

    igt@perf_pmu@busy-idle-check-all-rcs0:
      shard-snb:          INCOMPLETE (fdo#105411) -> PASS

    
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454
  fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

    * Linux: CI_DRM_4368 -> Patchwork_9399

  CI_DRM_4368: f9f621dc095a8bfd2157fba018ddb542260d8daa @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4528: 6be300d405de5974b262e8b93a445be4ac618e6a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9399: 244456cee448eceaa53681ec75c55edb0ff854c7 @ 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_9399/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/execlists: Check for ce->state before destroy

[Tvrtko Ursulin]

On 22/06/2018 11:57, Chris Wilson wrote:
> As we may cancel the ce->state allocation during context pinning (but
> crucially after we mark ce as operational), that means we may be asked
> to destroy a nonexistent ce->state. Given the choice in handing a
> complex error path on pinning, and just ignoring the lack of state in
> destroy, choice the latter for simplicity.
> 
> Reported-by: Zhao Yakui <yakui.zhao@intel.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
>   drivers/gpu/drm/i915/intel_lrc.c | 8 ++++++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> index 33bc914c2ef5..02ee3b12507f 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1337,11 +1337,15 @@ static void execlists_schedule(struct i915_request *request,
>   
>   static void execlists_context_destroy(struct intel_context *ce)
>   {
> -	GEM_BUG_ON(!ce->state);
>   	GEM_BUG_ON(ce->pin_count);
>   
> +	if (!ce->state)
> +		return;

Or set ce->ops only after success in execlists_context_pin? Sounds 
simpler and more logical unless I am missing something.

> +
> +	GEM_BUG_ON(i915_gem_object_is_active(ce->state->obj));
> +
>   	intel_ring_free(ce->ring);
> -	__i915_gem_object_release_unless_active(ce->state->obj);
> +	i915_gem_object_put(ce->state->obj);

Hm this bit is unexpected. I don't see an immediate intersect with the 
commit message and previous change. Intuitively it makes sense that 
ce->state->obj can/must never be active once here - but then doesn't 
this second part belong in a separate patch?

Regards,

Tvrtko

>   }
>   
>   static void execlists_context_unpin(struct intel_context *ce)
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/execlists: Check for ce->state before destroy

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-06-25 10:35:17)
> 
> On 22/06/2018 11:57, Chris Wilson wrote:
> > As we may cancel the ce->state allocation during context pinning (but
> > crucially after we mark ce as operational), that means we may be asked
> > to destroy a nonexistent ce->state. Given the choice in handing a
> > complex error path on pinning, and just ignoring the lack of state in
> > destroy, choice the latter for simplicity.
> > 
> > Reported-by: Zhao Yakui <yakui.zhao@intel.com>
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > ---
> >   drivers/gpu/drm/i915/intel_lrc.c | 8 ++++++--
> >   1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> > index 33bc914c2ef5..02ee3b12507f 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -1337,11 +1337,15 @@ static void execlists_schedule(struct i915_request *request,
> >   
> >   static void execlists_context_destroy(struct intel_context *ce)
> >   {
> > -     GEM_BUG_ON(!ce->state);
> >       GEM_BUG_ON(ce->pin_count);
> >   
> > +     if (!ce->state)
> > +             return;
> 
> Or set ce->ops only after success in execlists_context_pin? Sounds 
> simpler and more logical unless I am missing something.

The error handling!

If I do it this way, it is more consistent with virtual engine as there
ce->ops is not a good guide either. In ve, ops and state are set along
different paths.

In the future, I'm not so sure as then I expect ops to be set on
construction before pinning. But I am still planning on writing that...

> > +
> > +     GEM_BUG_ON(i915_gem_object_is_active(ce->state->obj));
> > +
> >       intel_ring_free(ce->ring);
> > -     __i915_gem_object_release_unless_active(ce->state->obj);
> > +     i915_gem_object_put(ce->state->obj);
> 
> Hm this bit is unexpected. I don't see an immediate intersect with the 
> commit message and previous change. Intuitively it makes sense that 
> ce->state->obj can/must never be active once here - but then doesn't 
> this second part belong in a separate patch?

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