[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1246842791.29532.2.camel@falcon>
Date: Mon, 06 Jul 2009 09:13:11 +0800
From: Wu Zhangjin <wuzhangjin@...il.com>
To: Krzysztof Helt <krzysztof.h1@...zta.fm>
Cc: Paul Mundt <lethal@...ux-sh.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
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"
Hi,
On Sun, 2009-07-05 at 18:18 +0200, Krzysztof Helt wrote:
> On Mon, 6 Jul 2009 00:25:57 +0900
> Paul Mundt <lethal@...ux-sh.org> 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 <lethal@...ux-sh.org>
> >
> > ---
> >
>
> This is incorrect way to fix this as some drivers do not use the framebuffer_alloc()
> 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 fb_info
> 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)?
>
This patch also works for me, thanks!
Regards,
Wu Zhangjin
> 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.
>
> Regards,
> Krzysztof
>
>
> From: Krzysztof Helt <krzysztof.h1@...pl>
>
> Remove redundant call to the sisfb_get_fix() before sis frambuffer is registered.
>
> This fixes a problem with uninitialized the fb_info->mm_lock mutex.
>
> Signed-off-by: Krzysztof Helt <krzysztof.h1@...pl>
> ---
>
> diff -urp linux-ref/drivers/video/sis/sis_main.c linux-next/drivers/video/sis/sis_main.c
> --- linux-ref/drivers/video/sis/sis_main.c 2009-07-01 18:07:05.000000000 +0200
> +++ linux-next/drivers/video/sis/sis_main.c 2009-07-05 17:20:33.000000000 +0200
> @@ -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 + ivideo->video_offset;
> 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
> http://link.interia.pl/f222
>
--
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/
Powered by blists - more mailing lists