[Intel-gfx] [RFC PATCH i-g-t 1/1] tests/gem_mmap_offset: Exercise mapping to userptr

Janusz Krzysztofik janusz.krzysztofik at linux.intel.com
Fri Jan 31 14:56:16 UTC 2020


On Friday, January 31, 2020 3:37:05 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-01-31 13:12:34)
> > Creating a mapping to a userptr backed GEM object may cause a currently
> > unavoidable lockdep splat inside the i915 driver.  Then, such operation
> > is expected to fail to prevent from that badness to happen.
> > 
> > Add a respective subtest for each mapping type.
> > 
> > Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik at linux.intel.com>
> > Cc: Matthew Auld <matthew.auld at intel.com>
> > Cc: Chris Wilson <chris at chris-wilson.co.uk>
> > ---
> >  tests/i915/gem_mmap_offset.c | 55 ++++++++++++++++++++++++++++++++++++
> >  1 file changed, 55 insertions(+)
> > 
> > diff --git a/tests/i915/gem_mmap_offset.c b/tests/i915/gem_mmap_offset.c
> > index 7c4088cdf..a5f28328b 100644
> > --- a/tests/i915/gem_mmap_offset.c
> > +++ b/tests/i915/gem_mmap_offset.c
> > @@ -141,6 +141,36 @@ static void bad_extensions(int i915)
> >         gem_close(i915, arg.handle);
> >  }
> >  
> > +static bool has_userptr(int i915)
> > +{
> > +       uint32_t handle = 0;
> > +       void *ptr;
> > +
> > +       igt_assert_eq(posix_memalign(&ptr, 4096, 4096), 0);
> > +       if (__gem_userptr(i915, ptr, 4096, 0, 0, &handle) == 0)
> > +               gem_close(i915, handle);
> > +       free(ptr);
> > +
> > +       return handle;
> > +}
> > +
> > +static void userptr(int i915, uint64_t flags)
> > +{
> > +       struct drm_i915_gem_mmap_offset arg = {
> > +               .flags = flags,
> > +       };
> > +       void *ptr;
> > +
> > +       igt_assert_eq(posix_memalign(&ptr, 4096, 4096), 0);
> > +
> > +       gem_userptr(i915, ptr, 4096, 0, 0, &arg.handle);
> > +
> > +       igt_assert_eq(mmap_offset_ioctl(i915, &arg), -EINVAL);
> 
> Not quite. The only reason it doesn't work is because the implementation
> ties itself into knots, not that it is meant to not work. :|

Are you suggesting the test should fail if the IOCTL fails?  That would be 
fair, but how are we going to have that accepted by CI then, and merged?

Skipping also doesn't seem a good option to me.

I can add some more exhaustive examination should the IOCTL succeed, but that 
won't help to make CI happy.

>From your long experience, what approach should we take?

Thanks,
Janusz


> -Chris
> 






More information about the Intel-gfx mailing list