[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