[Intel-gfx] [PATCH 17/37] drm/i915: Track vma activity per fence.context, not per engine

[Chris Wilson]

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