linux-kernel - Re: [RESEND PATCH 1/2] fb: reorder the lock sequence to fix potential dead lock

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Nov 2013 15:59:27 +0200
From:	Tomi Valkeinen <tomi.valkeinen@...com>
To:	Gu Zheng <guz.fnst@...fujitsu.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>
CC:	Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND PATCH 1/2] fb: reorder the lock sequence to fix potential
 dead lock

On 2013-11-05 12:00, Gu Zheng wrote:
> Following commits:
> 50e244cc79 fb: rework locking to fix lock ordering on takeover
> e93a9a8687 fb: Yet another band-aid for fixing lockdep mess
> 054430e773 fbcon: fix locking harder
> reworked locking to fix related lock ordering on takeover, and introduced console_lock
> into fbmem, but it seems that the new lock sequence(fb_info->lock ---> console_lock)
> is against with the one in console_callback(console_lock ---> fb_info->lock), and leads to
> a potential dead lock as following:

<snip>

> so we reorder the lock sequence the same as it in console_callback() to
> avoid this issue. And following Tomi's suggestion, fix these similar
> issues all in fb subsystem.
> 
> Signed-off-by: Gu Zheng <guz.fnst@...fujitsu.com>
> ---
>  drivers/video/fbmem.c            |   50 ++++++++++++++++++++++++-------------
>  drivers/video/fbsysfs.c          |   19 ++++++++++----
>  drivers/video/sh_mobile_lcdcfb.c |   10 ++++---
>  3 files changed, 51 insertions(+), 28 deletions(-)

I'll apply this for 3.13. It's a bit difficult to verify if the locking
is now correct, but looks fine to me. And we can revert this easily if
things break badly.

 Tomi



Download attachment "signature.asc" of type "application/pgp-signature" (902 bytes)