[Intel-gfx] [i-g-t 1/1] tests/gem_gtt_hog: Clear the parameters for GEM_CREATE ioctl

[Kamble, Sagar A]

On 3/20/2017 2:25 PM, Chris Wilson wrote:
> On Mon, Mar 20, 2017 at 02:16:54PM +0530, Kamble, Sagar A wrote:
>>
>> On 3/20/2017 1:11 PM, Chris Wilson wrote:
>>> On Mon, Mar 20, 2017 at 11:32:15AM +0530, Sagar Arun Kamble wrote:
>>>> Due to garbage data seen by i915, gem_create_ioctl failed for gem obj
>>>> created with drmIoctl(GEM_CREATE) without properly initialized
>>>> parameters. Can be fixed by calling gem_create helper too.
>>> Whose bug are you working around?
>>> -Chris
>> Found out now that this is happening due to mismatch in the libdrm headers 32bit/64bit flags for GEM_CREATE.
>> Able to resolve by properly using the proper definitions.
>> Will this fix be still applicable as flags would stay uninitialized with current call to drmIoctl?
> At the moment, create.pad is never tested ergo it is valid to contain
> garbage and as demonstrated that behaviour is already relied upon by
> userspace.
>
> How did the headers vary? The defintion is
> struct drm_i915_gem_create {
>          /**
>           * Requested size for the object.
>           *
>           * The (page-aligned) allocated size for the object will be returned.
>           */
>          __u64 size;
>          /**
>           * Returned handle for the object.
>           *
>           * Object handles are nonzero.
>           */
>          __u32 handle;
>          __u32 pad;
> };
> which should be 32/64bit safe. Otherwise we need a compat ioctl for the
> same reason as not breaking 32bit userspace on 64bit kernel.
> -Chris

This behavior is with internal Android kernel where gem_create has extra member as "__u64 flags"
added for stolen objects.
With pad value exception and size, handle set properly this patch does not apply then.

>