Re: BUG: circular locking dependency detected
From: Daniel Vetter <hidden>
Date: 2013-01-30 22:07:21
Also in:
dri-devel, lkml
On Wed, Jan 30, 2013 at 10:52 PM, Russell King [off-list ref] wrote:
Also adding Greg and Daniel to this as Daniel introduced the lockdep checking. This looks extremely horrid to be to solve - the paths are rather deep where the dependency occurs. The two paths between the locks are: console_lock+0x5c/0x70 register_con_driver+0x44/0x150 take_over_console+0x24/0x3b4 fbcon_takeover+0x70/0xd4 fbcon_event_notify+0x7c8/0x818 notifier_call_chain+0x4c/0x8c __blocking_notifier_call_chain+0x50/0x68 blocking_notifier_call_chain+0x20/0x28 and __blocking_notifier_call_chain+0x34/0x68 blocking_notifier_call_chain+0x20/0x28 fb_notifier_call_chain+0x20/0x28 fb_blank+0x40/0xac fbcon_blank+0x1f4/0x29c do_blank_screen+0x1b8/0x270 console_callback+0x74/0x138
You want Dave Airlie's pile of locking reworks, which fixes all currently known offenders around console_lock and fb_notifier. Patches won't go into 3.9 since it took a few rounds until they did not cause regression by making these deadlocks easier to hit. http://cgit.freedesktop.org/~airlied/linux/log/?hûcon-locking-fixes Long term solution would be to abolish the fb_notifier, at least for the purpose of linking fbdevs up with the fbcon and just replace those with direct function calls. But that requires that we no longer allow fbdev drivers and the fbcon to be loaded in any arbitrary order. Or just force fbcon to be built-in if enabled, imo the sane choice (no one's bothering with config_vt=m either, after all). Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch