Quoting Chris Wilson (2018-06-29 16:36:22)
> Quoting Tvrtko Ursulin (2018-06-29 16:08:40)
> >
> > On 29/06/2018 15:54, Tvrtko Ursulin wrote:
> >
> > [snip]
> >
> > >> +int i915_vma_move_to_active(struct i915_vma *vma,
> > >> + struct i915_request *rq,
> > >> + unsigned int flags)
> > >> +{
> > >> + struct drm_i915_gem_object *obj = vma->obj;
> > >> + struct i915_gem_active *active;
> > >> +
> > >> + lockdep_assert_held(&rq->i915->drm.struct_mutex);
> > >> + GEM_BUG_ON(!drm_mm_node_allocated(&vma->node));
> > >> +
> > >> + active = lookup_active(vma, rq->fence.context);
> > >
> > > Never mind the radix tree, but fence.context is u64 as well. And
> > > assigned values are continuously incrementing so once >4G of contexts
> > > are created and destroyed aliasing is guaranteed with the kernel
> > > context, or any old one.
> > >
> > > It is probably IGT abuse territory, but a) can we be sure it will not
> > > open up some exploit, and b) can we swallow this problem ourselves?
> >
> > Hm.. key the radix tree with the timeline pointer instead? 1:1 to
> > fence.context, natural long, and automatic lifetime management.
>
> Lets see.
Counter argument is density. timeline pointers are going to be much
sparser than my expectations around context id (even with the silly
incrementing u64).
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
