| Message ID | 1376979255-17887-2-git-send-email-benjamin.widawsky@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 9b3b5f8..7d8c841 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -516,6 +516,8 @@ i915_gem_execbuffer_unreserve_vma(struct i915_vma *vma) i915_gem_object_unpin(obj); entry->flags &= ~(__EXEC_OBJECT_HAS_FENCE | __EXEC_OBJECT_HAS_PIN); + + vma->busy = 0; } static int @@ -535,6 +537,7 @@ i915_gem_execbuffer_reserve(struct intel_ring_buffer *ring, bool need_fence, need_mappable; vma = list_first_entry(vmas, struct i915_vma, exec_list); + vma->busy = true; obj = vma->obj; entry = vma->exec_entry;
The exec_list is a somewhat fragile list containing all the VMAs we've looked up. It does processing in a multi-stage approach where elements on the list are expected to not be removed for the duration of the stages. The next patch will fix an oversight where destroying a VMA does not remove it from the exec_list. As such, we must mark the VMA busy for the multi stage execbuf or else the above assertion we mentioned cannot be guaranteed. NOTE: This patch isn't quite tested yet. It just fixes the theoretical issue. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 +++ 1 file changed, 3 insertions(+)