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 know it might be equally confusing, too, when only a small portion of the function is mocked. Especially if it's more of a side-effect like here. Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
