On Mon, Sep 8, 2014 at 7:27 AM, Michael N. Henry mnhenry333@gmail.com wrote:
crtc->mutex is acquired in drm_modeset_lock_crtc(). The next call to drm_modeset_unlock_crt() would not unlock it, causing a deadlock during the next call to drm_modest_lock_crtc().
drivers/gpu/drm/drm_modeset_lock.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c index 474e4d1..fab3aa8 100644 --- a/drivers/gpu/drm/drm_modeset_lock.c +++ b/drivers/gpu/drm/drm_modeset_lock.c @@ -236,6 +236,8 @@ void drm_modeset_unlock_crtc(struct drm_crtc *crtc) drm_modeset_drop_locks(ctx); drm_modeset_acquire_fini(ctx);
drm_modeset_unlock(&crtc->mutex);
drm_mode_drop_locks should drop all mutexes (and so also the crtc mutex acquired with ctx. Also acquire_fini should complain if you unlock afterwards.
I suspect that some other caller completely forgets to unlock the crtc somehow, but I can't see where that happens. Can you please re-run with CONFIG_PROVE_LOCKING enabled in your kernel build?
And a small nitpick on your patch submission: When you submit just one patch, please don't do a cover letter - all the information you provide in there (backtrace, bisect result) should be part of the commit message anyway. And your patch is missing the signed-off-by line, so can't be merged. And please also don't forget to cc relevant mailing lists.
Thanks, Daniel
dri-devel@lists.freedesktop.org