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@xxxxxxxxxxxxxxxxxx> > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
