While in real life, we could never fail to grab the newly created mutex, ww_mutex fault injection has no way to know this. Which could result that kernels built with CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y might fail to acquire the new crtc lock. Which results in bad things when the locks are dropped. See: https://bugzilla.kernel.org/show_bug.cgi?id=83341 Signed-off-by: Rob Clark <robdclark@xxxxxxxxx> --- drivers/gpu/drm/drm_crtc.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 7d7c1fd..8bb11fa 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -682,7 +682,15 @@ int drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc, drm_modeset_lock_all(dev); drm_modeset_lock_init(&crtc->mutex); /* dropped by _unlock_all(): */ - drm_modeset_lock(&crtc->mutex, config->acquire_ctx); + /* NOTE: use trylock here for the benefit of ww_mutex fault + * injection. We cannot actually fail to grab this lock (as + * it has only just been created), but fault injection does + * not know this, which can result in the this lock failing, + * and hilarity when we later try to drop the locks. See: + * https://bugzilla.kernel.org/show_bug.cgi?id=83341 + */ + ret = ww_mutex_trylock(&crtc->mutex.mutex); + WARN_ON(ret); ret = drm_mode_object_get(dev, &crtc->base, DRM_MODE_OBJECT_CRTC); if (ret) -- 1.9.3 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
