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
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
