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@xxxxxxxxxxxxxxxxxx> > > Cc: Matthew Auld <matthew.auld@xxxxxxxxx> > > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > > <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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
