drm/atomic: Add WARN_ON when state->acquire_ctx is not set.
When I was writing an atomic wrapper for rmfb, I ran into the following backtrace from lockdep: ============================================= [ INFO: possible recursive locking detected ] 4.5.0-patser+ #4696 Tainted: G U --------------------------------------------- kworker/2:2/2608 is trying to acquire lock: (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffc00c9ddc>] drm_modeset_lock+0x7c/0x120 [drm] but task is already holding lock: (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffc00c98cd>] modeset_backoff+0x8d/0x220 [drm] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(crtc_ww_class_mutex); lock(crtc_ww_class_mutex); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by kworker/2:2/2608: #0: ("events"){.+.+.+}, at: [<ffffffff810a5eea>] process_one_work+0x15a/0x6c0 #1: ((&arg.work)){+.+.+.}, at: [<ffffffff810a5eea>] process_one_work+0x15a/0x6c0 #2: (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffffc004532a>] drm_atomic_helper_remove_fb+0x4a/0x1d0 [drm_kms_helper] #3: (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffc00c98cd>] modeset_backoff+0x8d/0x220 [drm] While lockdep probably catches this bug when it happens, it's better to explicitly warn when state->acquire_ctx is not set. Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1462266751-29123-1-git-send-email-maarten.lankhorst@linux.intel.com
Showing
想要评论请 注册 或 登录