Quoting Chris Wilson (2019-02-06 16:08:23) > 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. It's even clearer than that since the write to the bit has an explicit barrier. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
