On 29/06/2018 16:39, Chris Wilson wrote:
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).
Or maybe something built from the basis of i915_syncmap? Same keys and
same lifetime, just the stored data is different.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
