linux-kernel - Re: Recursive lock in fbcon after unblank and modelist change

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20110112004319.GA24367@gandalf>
Date:	Wed, 12 Jan 2011 00:43:19 +0000
From:	James Hogan <james@...anarts.com>
To:	linux-fbdev@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Recursive lock in fbcon after unblank and modelist change

CC'ing lkml in hopes that somebody might be able to answer my questions:

On Fri, Jan 07, 2011 at 12:55:09PM +0000, James Hogan wrote:
> Hi,
> 
> I'm hitting the following recursive locking problem when unblanking
> the framebuffer (echoing 3 then 0 to /sys/class/graphics/fb0/blank).
> 
> Basically this is what's happening:
> * the fb_blank function sends the blank notification
> * fbcon gets the blank notification, and calls fbcon_switch
> * fbcon_switch calls fb_set_var
> * fb_set_var actually makes a change, which triggers another
> notification (mode change), which tries to lock fb_notifier_list.rwsem
> again, which triggers the lockdep warning (and presumably potentially
> a deadlock).
> 
> The reason fb_set_var makes a change is because the mode list has been
> updated since the last mode change, so the current mode is effectively
> out of date. E.g. this could be done by writing to
> /sys/class/graphics/fb0/modes, or in my case an HDMI driver updates
> the modelist on a monitor hotplug event after reading the EDID in the
> same way as the sysfs interface.
> 
> So, a few questions:
> (1) Is this situation a valid situation, where the modelist has been
> overwritten but current mode left unchanged?
> (2) If (1), any ideas how the recursive locking situation should be resolved?
> (3) If not (1), should updating the modelist using sysfs (and
> similarly on a monitor hotplug event), also update the current mode to
> the nearest mode in the list (fb_new_modelist would seem an
> appropriate place)?
> 
> Thanks
> James
> 
> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.37-rc7+ #1435
> ---------------------------------------------
> sh/382 is trying to acquire lock:
>  ((fb_notifier_list).rwsem){.+.+.+}, at: [<40040a60>]
> ___blocking_notifier_call_chain+0x34/0x80
> 
> but task is already holding lock:
>  ((fb_notifier_list).rwsem){.+.+.+}, at: [<40040a60>]
> ___blocking_notifier_call_chain+0x34/0x80
> 
> other info that might help us debug this:
> 3 locks held by sh/382:
>  #0:  (&buffer->mutex){+.+.+.}, at: [<400e8ab0>] _sysfs_write_file+0x38/0x1a4
>  #1:  (s_active#13){.+.+.+}, at: [<400e8ba0>] _sysfs_write_file+0x128/0x1a4
>  #2:  ((fb_notifier_list).rwsem){.+.+.+}, at: [<40040a60>]
> ___blocking_notifier_call_chain+0x34/0x80
> 
> stack backtrace:
> 
> Call trace:
> [<40003b1c>] _show_stack+0x68/0x7c
> [<40003b44>] _dump_stack+0x14/0x28
> [<4004f360>] _validate_chain+0x1170/0x137c
> [<4004f9dc>] ___lock_acquire+0x470/0xc44
> [<4005020c>] _lock_acquire+0x5c/0x84
> [<40238204>] _down_read+0x48/0x64
> [<40040a5c>] ___blocking_notifier_call_chain+0x30/0x80
> [<40040ac0>] _blocking_notifier_call_chain+0x14/0x28
> [<401332ac>] _fb_notifier_call_chain+0x1c/0x30
> [<40134894>] _fb_set_var+0x170/0x324
> [<40141e98>] _fbcon_switch+0x1b8/0x5a4
> [<401635d4>] _redraw_screen+0x100/0x268
> [<401424bc>] _fbcon_blank+0x238/0x2e0
> [<40163834>] _do_unblank_screen+0xf8/0x200
> [<40140aa8>] _fbcon_event_notify+0xae0/0xae8
> [<40040608>] _notifier_call_chain+0x48/0x94
> [<40040a74>] ___blocking_notifier_call_chain+0x48/0x80
> [<40040ac0>] _blocking_notifier_call_chain+0x14/0x28
> [<401332ac>] _fb_notifier_call_chain+0x1c/0x30
> [<40133938>] _fb_blank+0x7c/0xa8
> [<40139964>] _store_blank+0x50/0x84
> [<401739ec>] _dev_attr_store+0x20/0x48
> [<400e8bc0>] _sysfs_write_file+0x148/0x1a4
> [<4009180c>] _vfs_write+0xec/0x194
> [<40092168>] _sys_write+0x40/0x90
> [<4000460c>] _switch_handler+0x110/0x170
> [<40001098>] ___TBIBoingVec+0xc/0x10
> 
> INFO: lockdep is turned off.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/