[Top] [All Lists]

Re: [BUG] drivers/video/sis: deadlock introduced by "fbdev: add mutex fo

To: Paul Mundt <>
Subject: Re: [BUG] drivers/video/sis: deadlock introduced by "fbdev: add mutex for fb_mmap locking"
From: Krzysztof Helt <>
Date: Sun, 5 Jul 2009 18:18:08 +0200
Cc: Linus Torvalds <>, Wu Zhangjin <>,,,, Krzysztof Helt <>, Peter Zijlstra <>, "Rafael J. Wysocki" <>, Andrew Morton <>, Ralf Baechle <>, ???? <>, zhangfx <>
In-reply-to: <>
Original-recipient: rfc822;
References: <1246785112.14240.34.camel@falcon> <alpine.LFD.2.01.0907050715490.3210@localhost.localdomain> <> <alpine.LFD.2.01.0907050756280.3210@localhost.localdomain> <> <alpine.LFD.2.01.0907050816110.3210@localhost.localdomain> <>
On Mon, 6 Jul 2009 00:25:57 +0900
Paul Mundt <> wrote:

> On Sun, Jul 05, 2009 at 08:19:40AM -0700, Linus Torvalds wrote:
> > 
> > 
> > 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.
> > 
> Ok, here is an updated version with an updated matroxfb and the sm501fb
> change reverted.
> Signed-off-by: Paul Mundt <>
> ---

This is incorrect way to fix this as some drivers do not use the 
at all. They use global (for a file) fb_info structure. I have done some 
cleanups to
the fbdev layer before the 2.6.31 and there should no drivers which uses 
kmalloc or
kzalloc to allocate the fb_info (your patch would break these drivers too).

A root of the whole mm_lock issue is that the fb_mmap() BKL protected two 
fields which were never protected when set. I changed this by add the mm_lock 
around these fields but only in drivers which modified this fields AFTER call
to the register_framebuffer(). Some drivers set these fields using the same
function before and after the register_framebuffer(). I strongly believe that
setting these fields before the register_framebuffer() is wrong or redundant for
these drivers. See my fix for the sisfb driver below. 

I have tested the patch below. Wu Zhangjin, can you also confirm that this 
works for you (without your patch)?

I will look into the matroxfb and sm501fb drivers now. The same problem is
already fixed for the mx3fb driver and the patch is sent to Andrew Morton.


From: Krzysztof Helt <>

Remove redundant call to the sisfb_get_fix() before sis frambuffer is 

This fixes a problem with uninitialized the fb_info->mm_lock mutex.

Signed-off-by: Krzysztof Helt <>

diff -urp linux-ref/drivers/video/sis/sis_main.c 
--- linux-ref/drivers/video/sis/sis_main.c      2009-07-01 18:07:05.000000000 
+++ linux-next/drivers/video/sis/sis_main.c     2009-07-05 17:20:33.000000000 
@@ -6367,7 +6367,6 @@ error_3:  vfree(ivideo->bios_abase);
                sis_fb_info->fix = ivideo->sisfb_fix;
                sis_fb_info->screen_base = ivideo->video_vbase + 
                sis_fb_info->fbops = &sisfb_ops;
-               sisfb_get_fix(&sis_fb_info->fix, -1, sis_fb_info);
                sis_fb_info->pseudo_palette = ivideo->pseudo_palette;
                fb_alloc_cmap(&sis_fb_info->cmap, 256 , 0);

Najlepsze OC i AC tylko w Ergo Hestia

<Prev in Thread] Current Thread [Next in Thread>