lkml.org 
[lkml]   [2009]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2009-10-18 23:28    [W:0.041 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site