[Intel-gfx] [PATCH 9/9] drm/i915: Fail the execbuff using stolen objects as batchbuffers

Dave Gordon david.s.gordon at intel.com
Tue Dec 15 06:41:47 PST 2015


On 14/12/15 05:46, ankitprasad.r.sharma at intel.com wrote:
> From: Ankitprasad Sharma <ankitprasad.r.sharma at intel.com>
>
> 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 at intel.com>
> ---
>   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);
>



More information about the Intel-gfx mailing list