On Wed, Jan 30, 2013 at 11:07:16PM +0100, Daniel Vetter wrote:
On Wed, Jan 30, 2013 at 10:52 PM, Russell King rmk@arm.linux.org.uk 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=fbcon-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).
So... what you seem to be telling me is that 3.9 is going to be a release which issues lockdep complaints when the console blanks, and you think that's acceptable?
Adding Linus and Andrew so they're aware of this issue...