Quoting Mika Kuoppala (2019-06-10 10:46:43)
> Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes:
> > static int i915_gem_fence_regs_info(struct seq_file *m, void *data)
> > {
> > - struct drm_i915_private *dev_priv = node_to_i915(m->private);
> > - struct drm_device *dev = &dev_priv->drm;
> > - int i, ret;
> > + struct drm_i915_private *i915 = node_to_i915(m->private);
> > + unsigned int i;
> >
> > - ret = mutex_lock_interruptible(&dev->struct_mutex);
> > - if (ret)
> > - return ret;
> > + seq_printf(m, "Total fences = %d\n", i915->ggtt.num_fences);
> >
> > - seq_printf(m, "Total fences = %d\n", dev_priv->num_fence_regs);
> > - for (i = 0; i < dev_priv->num_fence_regs; i++) {
> > - struct i915_vma *vma = dev_priv->fence_regs[i].vma;
> > + rcu_read_lock();
>
> This does not seem to be for reset. So it must be for keeping
> the object alive.
Correct.
> What guarantees that the obj is kept alive over this rcu
> lock?
That the object is RCU protected. :-p
It is a relatively simple one (it used to be manual RCU barriers),
i915_gem_free_object() uses call_rcu() to only queue the object for
freeing after an RCU grace period has elapsed.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
