Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes:
> 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.
I was grepping for synchronize_rcu and ended up confused. This
is what I was looking for.
Reviewed-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
