Re: [PATCH 2/6] drm/i915/gem: Avoid gem_context->mutex for simple vma lookup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux