Quoting Chris Wilson (2020-03-19 14:52:21)
> Quoting Tvrtko Ursulin (2020-03-19 14:20:04)
> >
> > On 19/03/2020 09:19, Chris Wilson wrote:
> > > +static struct i915_vma *eb_lookup_vma(struct i915_execbuffer *eb, u32 handle)
> > > +{
> > > + do {
> > > + struct drm_i915_gem_object *obj;
> > > struct i915_vma *vma;
> > > + int err;
> > >
> > > - vma = radix_tree_lookup(handles_vma, handle);
> > > + rcu_read_lock();
> > > + vma = radix_tree_lookup(&eb->gem_context->handles_vma, handle);
> >
> > radix_tree_lookup is documented to be RCU safe okay. How about freeing
> > VMAs - is that done after a RCU grace period?
>
> As we are still stuck with the horrible i915_vma.kref semantics (yes, I
> know I'm supposed to be fixing that), there are 3 paths which may
> destroy i915_vma: the object (RCU safe), the vm (RCU safe) and
> i915_vma_parked, not safe in any way shape or form.
Actually, the nasty fact I keep forgetting is that i915_vma_parked is
serialised with execbuf by virtue of the engine-pm. That has caught me
out many times, but is why this is safe (and takes extra effort to
convert to kref).
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
