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?
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

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.

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

Reply via email to