On Mon, Sep 8, 2014 at 7:27 AM, Michael N. Henry <mnhenry333@xxxxxxxxx> 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
