[Intel-gfx] [PATCH i-g-t 1/3] aubdump: Reject execbuffer2 calls with bad BOs

[Lionel Landwerlin]

Heh, fixed the same in ksim. Don't know why I didn't see it while using 
aubdump recently...

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin at intel.com>

On 23/08/17 18:14, Jason Ekstrand wrote:
> This is required for the supports_48b_addresses check in the Vulkan
> driver to work without messing up the resulting aub.
> ---
>   tools/aubdump.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
>
> diff --git a/tools/aubdump.c b/tools/aubdump.c
> index 610526c..c14c9fa 100644
> --- a/tools/aubdump.c
> +++ b/tools/aubdump.c
> @@ -426,6 +426,12 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 *execbuffer2)
>   		obj = &exec_objects[i];
>   		bo = get_bo(obj->handle);
>   
> +		/* If bo->size == 0, this means they passed us an invalid
> +		 * buffer.  The kernel will reject it and so should we.
> +		 */
> +		if (bo->size == 0)
> +			return;
> +
>   		if (obj->flags & EXEC_OBJECT_PINNED) {
>   			bo->offset = obj->offset;
>   		} else {
> @@ -475,6 +481,7 @@ add_new_bo(int handle, uint64_t size, void *map)
>   	struct bo *bo = &bos[handle];
>   
>   	fail_if(handle >= MAX_BO_COUNT, "intel_aubdump: bo handle out of range\n");
> +	fail_if(size == 0, "intel_aubdump: bo size is invalid\n");
>   
>   	bo->size = size;
>   	bo->map = map;
> @@ -487,6 +494,7 @@ remove_bo(int handle)
>   
>   	if (bo->map && !IS_USERPTR(bo->map))
>   		munmap(bo->map, bo->size);
> +	bo->size = 0;
>   	bo->map = NULL;
>   }
>