On 14/12/15 05:46, ankitprasad.r.sharma@xxxxxxxxx wrote:
From: Ankitprasad Sharma <ankitprasad.r.sharma@xxxxxxxxx> Using stolen backed objects as a batchbuffer may result into a kernel panic during relocation. Added a check to prevent the panic and fail the execbuffer call. It is not recommended to use stolen object as a batchbuffer. Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@xxxxxxxxx> --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 48ec484..d342f10 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -462,7 +462,9 @@ i915_gem_execbuffer_relocate_entry(struct drm_i915_gem_object *obj, if (obj->active && pagefault_disabled()) return -EFAULT; - if (use_cpu_reloc(obj)) + if (obj->stolen) + ret = -EINVAL;
I'd rather reject ALL "weird" gem objects at the first opportunity, so that none of the execbuffer code has to worry about stolen, phys, dmabuf, etc ... if (obj->ops != &i915_gem_object_ops)) ret = -EINVAL; /* No exotica please */ .Dave.
+ else if (use_cpu_reloc(obj)) ret = relocate_entry_cpu(obj, reloc, target_offset); else if (obj->map_and_fenceable) ret = relocate_entry_gtt(obj, reloc, target_offset);
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
