[Intel-gfx] [PATCH] drm/i915: Flush context free work on cleanup

[Chris Wilson]

Quoting Tvrtko Ursulin (2019-11-12 13:55:35)
> 
> On 12/11/2019 09:06, Chris Wilson wrote:
> > Throw in a flush_work() and rcu_barrier() to specifically flush the
> > context cleanup work.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112248
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> 
> Fixes: a4e7ccdac38e ("drm/i915: Move context management under GEM")
> 
> ? Might have gotten it wrong.. only did a quick dig.

Seems reasonable, I was thinking without an explicit flush we are at the
mercy of the flush_workqueue(), hence why we have so many! :) But yes,
the switch from i915->wq to system_wq does mean a new requirement for
the global flush whose name escapes me right now.

> > ---
> >   drivers/gpu/drm/i915/gem/i915_gem_context.c | 1 +
> >   drivers/gpu/drm/i915/gt/intel_engine_cs.c   | 1 +
> >   2 files changed, 2 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 72d389afa28a..17f395672e5e 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -776,6 +776,7 @@ int i915_gem_init_contexts(struct drm_i915_private *i915)
> >   void i915_gem_driver_release__contexts(struct drm_i915_private *i915)
> >   {
> >       destroy_kernel_context(&i915->kernel_context);
> > +     flush_work(&i915->gem.contexts.free_work);
> >   }
> >   
> >   static int context_idr_cleanup(int id, void *p, void *data)
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index b9613d044393..1f68700a2311 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -402,6 +402,7 @@ void intel_engines_cleanup(struct intel_gt *gt)
> >               gt->engine[id] = NULL;
> >               gt->i915->engine[id] = NULL;
> >       }
> > +     rcu_barrier();
> 
> Why this?

It's so we play catch up the RCU free_work of the ppgtt that we trigger
here and we need to be confident has been queued before we do its fini.

I was acting on a memory of a similar debugobject splat, quite possibly
over-reacting.
-Chris