linux-kernel - Re: [BUG] drivers/video/sis: deadlock introduced by "fbdev: add mutex for fb

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:	Sun, 5 Jul 2009 08:19:40 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Paul Mundt <lethal@...ux-sh.org>
cc:	Wu Zhangjin <wuzhangjin@...il.com>, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mips@...ux-mips.org,
	Krzysztof Helt <krzysztof.h1@...pl>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ralf Baechle <ralf@...ux-mips.org>, ???? <yanh@...ote.com>,
	zhangfx <zhangfx@...ote.com>
Subject: Re: [BUG] drivers/video/sis: deadlock introduced by "fbdev: add
 mutex for fb_mmap locking"

On Mon, 6 Jul 2009, Paul Mundt wrote:
> >
> > Why not "lock" as well?
> 
> I had that initially, but matroxfb will break if we do that, and
> presently nothing cares about trying to take ->lock that early on.

I really would rather have consistency than some odd rules like that.

In particular - if matroxfb is different and needs its own lock 
initialization because it doesn't use the common allocation routine, then 
please make _that_ consistent too. Rather than have it special-case just 
one lock that it needs to initialize separately, make it clear that since 
it does its own allocations it needs to initialize _everything_ 
separately.

Otherwise anybody grepping for things will always be confused, since 
depending on random factors they'll notice the initializations in one 
place or the other, and then do the wrong thing - exactly like mm_lock was 
not correctly initialized this time around.

In other words: it's actually _better_ to make the matroxfb pain _more_ 
obvious rather than less.

And maybe we can deprecate the driver, throw it out entirely, or have 
somebody actually fix it?

			Linus
--
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/