Quoting Mika Kuoppala (2019-02-06 15:56:28) > Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > > @@ -5358,6 +5326,8 @@ void i915_gem_cleanup_early(struct drm_i915_private *dev_priv) > > GEM_BUG_ON(atomic_read(&dev_priv->mm.free_count)); > > WARN_ON(dev_priv->mm.object_count); > > > > synchronize_rcu and srcu and GEM_BUG_ON for reset backoff? There can't be any readers by this point, and we don't use call_[s]rcu so no deferred tasks to worry about. I don't see anything that we can bug on to prove that though. > > @@ -1274,9 +1270,12 @@ void i915_handle_error(struct drm_i915_private *i915, > > wait_event(i915->gpu_error.reset_queue, > > !test_bit(I915_RESET_BACKOFF, > > &i915->gpu_error.flags)); > > - goto out; > > + goto out; /* piggy-back on the other reset */ > > } > > > > I should have been more specific in last run, sorry. Still errorneous > comment above test_and_set_bit(I915_RESET_BACKOFF). > > Also as I understood from RCU/checklist.txt the rcu provides > no help for read ordering here. The test_and_set_bit provides > the mb on this side. But add smp_mb__before_atomic before > sampling the the bit in trylock? Wrong side, you apply that to the writer and we have the implicit mb in the wakeup already for the write. The atomic reads are just fine in conjunction with wait event serialisation. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
