[Intel-gfx] [PATCH] drm/i915/selftests: Avoid drm_gem_handle_create under struct_mutex
Joonas Lahtinen
joonas.lahtinen at linux.intel.com
Tue Nov 21 13:01:43 UTC 2017
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 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 at linux.intel.com>
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
More information about the Intel-gfx
mailing list