[Intel-gfx] [PATCH] drm/i915/selftests: Avoid drm_gem_handle_create under struct_mutex

[Chris Wilson]

Quoting Joonas Lahtinen (2017-11-21 13:01:43)
> On Tue, 2017-11-21 at 11:06 +0000, Chris Wilson wrote:
> > Despite us reloading the module around every selftest, the lockclasses
> > persist and the chains used in selftesting may then dictate how we are
> > allowed to nest locks during runtime testing. As such we have to be just
> > as careful, and in particular it turns out we are not allowed to nest
> > dev->object_name_lock (drm_gem_handle_create) inside dev->struct_mutex.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103830
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Matthew Auld <matthew.auld at intel.com>
> > Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> 
> <SNIP>
> 
> > @@ -283,8 +299,7 @@ create_test_object(struct i915_gem_context *ctx,
> >       if (IS_ERR(obj))
> >               return obj;
> >  
> > -     /* tie the handle to the drm_file for easy reaping */
> > -     err = drm_gem_handle_create(file, &obj->base, &handle);
> > +     err = file_add_object(file, obj);
> 
> Should we have a more direct connection between the substituted mock
> function names? So should we have mock_drm_gem_handle_create, and it'll
> then mock that function only for the interesting parts, like here.

I was thinking more along the lines of trying to split drm_gem.c, to
provide internal access. Along those lines we could start moving some of
the grubby bending-of-the-rules stuff we want to test those rules into
drm itself.

Hmm, that's an idea. Certainly we need more coverage of things like the
drm_vma_manager api, so the drm-st library will need to grow.
-Chris