[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090411080415.7fe924a2.krzysztof.h1@poczta.fm>
Date: Sat, 11 Apr 2009 08:04:15 +0200
From: Krzysztof Helt <krzysztof.h1@...zta.fm>
To: Andrea Righi <righi.andrea@...il.com>
Cc: Eric Miao <eric.y.miao@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Andrey Borzenkov <arvidjaar@...il.com>,
"Antonino A. Daplas" <adaplas@...il.com>,
linux-fbdev-devel@...ts.sourceforge.net,
linux-pm@...ts.linux-foundation.org, Dave Jones <davej@...hat.com>,
Harvey Harrison <harvey.harrison@...il.com>,
Johannes Weiner <hannes@...xchg.org>,
Stefan Richter <stefanr@...6.in-berlin.de>
Subject: Re: [REGRESSION] commit 66c1ca0: {fbmem: fix fb_info->lock and
mm->mmap_sem ...} causes Xfbdev not working
On Sat, 11 Apr 2009 00:05:22 +0200
Andrea Righi <righi.andrea@...il.com> wrote:
>
> mmmh... I may have missed something, but the common fb_mmap() should
> acquire mm->mmap_sem and then info->lock, while fb_ioctl() can do that
> in reverse order (info->lock first and then mm->mmap_sem) causing the
> circular locking dependency. Are you sure that pushing info->lock down
> each driver's fb_mmap will fix the problem?
Right. The fb_mmap is called with the mmap_sem already held.
I will try other possibilities like breaking info->lock() into two
mutexex.
Something should be done to solve this problem.
Best regards,
Krzysztof
----------------------------------------------------------------------
Oblej swoich znajomych... wirtualnie! ;)
http://link.interia.pl/f2119
--
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