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.
A quick and dirty solution would be to move i915_vma_parked behind an
rcu work.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
