Re: [igt-dev] [PATCH i-g-t 1/2] tests/gem_ctx_bad_exec: Consolidate to gem_ctx_exec

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Tvrtko Ursulin (2018-09-18 11:33:14)
> 
> On 18/09/2018 11:03, Chris Wilson wrote:
> > Quoting Chris Wilson (2018-09-18 11:02:09)
> >> Quoting Tvrtko Ursulin (2018-09-18 10:59:11)
> >>>
> >>> On 18/09/2018 10:44, Chris Wilson wrote:
> >>>> Quoting Tvrtko Ursulin (2018-09-18 10:38:44)
> >>>>> Can I say it is testing the i915_execbuffer2_set_context_id as well by
> >>>>> knowing underlying ABI field is 64-bit wide and keep the r-b? (No trash
> >>>>> in unused part of rsvd1.)
> >>>>
> >>>> The field isn't 64-bit wide, so the test would be misleading unfortunately.
> >>>
> >>> rsvd1? It is 64-bit in i915_drm.h I am looking at. And ABI is free to
> >>> set it directly.
> >>>
> >>> But true, it seems we are not checking for trash in upper 32-bits in
> >>> execbuf paths.. :(
> >>>
> >>> So this means regardless of what helper does the ABI is actually 64-bit.
> >>> So test should actually bypass the helper I think and set rsvd1 directly
> >>> I think. And keep the 64-bit invalid values.
> >>
> >> We are not checking 64b. Think of one value that invalidates the test.
> 
> eb.rsdvd = ctx << 32; always gives you the default context?
> 
> But is ABI the macro helper or the comment in i915_drm.h against rsvd1?
> 
> Probably the main problem is that we forgot to check for trash in upper 
> bits..
> 
> Or in other words, what do you want to see here in terms of invalid 
> values and helper or not? Stick to 32-bits just because that's where we 
> are now with the historical implementation?

The context id ABI has always been u32, and that's the field under test.

> > We can construct more values that would fail if we create a few contexts
> > and destroy them testing that that are invalid after use.
> 
> Hello scope creep, okay, I'll add it.

The test is "invalid context id" :-p Feature creep would be identifying
that we have several tests that poke at IDRs through the ABI that could
be refactored into a framework for light fuzzing.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux