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.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
