| Message ID | 1489989735-15462-1-git-send-email-sagar.a.kamble@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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? >
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
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. >
diff --git a/tests/gem_gtt_hog.c b/tests/gem_gtt_hog.c index a3dbfad..0696bdc 100644 --- a/tests/gem_gtt_hog.c +++ b/tests/gem_gtt_hog.c @@ -93,6 +93,7 @@ static void busy(data_t *data, uint32_t handle, int size, int loops) gem_exec[0].handle = handle; gem_exec[0].flags = EXEC_OBJECT_NEEDS_FENCE; + memset(&create, 0, sizeof(create)); create.handle = 0; create.size = 4096; drmIoctl(data->fd, DRM_IOCTL_I915_GEM_CREATE, &create);
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. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lukasz Kalamarz <lukasz.kalamarz@intel.com> Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> --- tests/gem_gtt_hog.c | 1 + 1 file changed, 1 insertion(+)