From: Andrea Righi <righi.andrea@gmail.com>
To: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: Eric Miao <eric.y.miao@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Andrey Borzenkov <arvidjaar@gmail.com>,
"Antonino A. Daplas" <adaplas@gmail.com>,
linux-fbdev-devel@lists.sourceforge.net,
linux-pm@lists.linux-foundation.org,
Dave Jones <davej@redhat.com>,
Harvey Harrison <harvey.harrison@gmail.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Stefan Richter <stefanr@s5r6.in-berlin.de>
Subject: Re: [REGRESSION] commit 66c1ca0: {fbmem: fix fb_info->lock and mm->mmap_sem ...} causes Xfbdev not working
Date: Sat, 11 Apr 2009 00:05:22 +0200 [thread overview]
Message-ID: <20090410220521.GB21294@linux> (raw)
In-Reply-To: <20090410222122.87be60f6.krzysztof.h1@poczta.fm>
On Fri, Apr 10, 2009 at 10:21:22PM +0200, Krzysztof Helt wrote:
> On Thu, 9 Apr 2009 14:58:51 +0200
> Andrea Righi <righi.andrea@gmail.com> wrote:
>
> > On Thu, Apr 09, 2009 at 07:36:24PM +0800, Eric Miao wrote:
> > > This happens on my Marvell PXA310-based Littleton platform with
> > > Angstrom Distribution. The offending paths are many:
> > >
> > > FBIOPUT_VSCREENINFO:
> > > lock_fb_info()
> > > --> fb_set_var()
> > > --> fb_notifier_call_chain() [FBINFO_MISC_USEREVENT]
> > > --> fbcon_event_notifier() [FB_EVENT_MODE_CHANGE]
> > > --> lock_fb_info()
> > >
> > > OK, now hang. I'd suggest a clean fix to the original assumption of
> > > circular locking
> > > issue and revert this commit first.
> > >
> > > --
> > > Cheers
> > > - eric
> >
> > I can agree to revert 66c1ca019078220dc1bf968f2bb18421100ef147, since I
> > don't have a clean fix for this. Pushing down fb_info->lock in
> > fb_set_var() excluding to call fb_notifier_call_chain with fb_info->lock
> > held doesn't seem to be so trivial...
> >
> > However, reverting this will re-introduce the circular locking
> > dependency fb_info->lock => mm->mmap_sem => fb_info->lock.
> >
>
> If anybody is interested I have looked into the code of the fb_mmap()
> and have found that the problem Andrea tried to fix is caused
> only by drivers which implements their own fb_mmap().
Krzysztof,
first of all thanks for looking into the code!
>
> The correct solution is to push the info->lock mutex into
> the fb_mmap() implemented inside the drivers. Some drivers
> may not need it (the ones which only calculate offsets
> and do not "real" iommaping).
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?
>
> I'll try to prepare a patch after the Easters. This will require a revert
> of the 66c1ca commit.
Thanks and happy Easter,
-Andrea
>
> Happy Easters,
> Krzysztof
>
> ----------------------------------------------------------------------
> Nagrody w jednym miejscu!
> Sprawdz >> http://link.interia.pl/f210b
>
next prev parent reply other threads:[~2009-04-10 22:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <f17812d70904090436kd03744brca4a4bc4b85bba8@mail.gmail.com>
2009-04-09 12:58 ` [REGRESSION] commit 66c1ca0: {fbmem: fix fb_info->lock and mm->mmap_sem ...} causes Xfbdev not working Andrea Righi
2009-04-10 20:21 ` Krzysztof Helt
2009-04-10 21:16 ` Andrew Morton
2009-04-10 22:05 ` Andrea Righi [this message]
2009-04-11 6:04 ` Krzysztof Helt
[not found] ` <49E05C36.9040204@s5r6.in-berlin.de>
2009-04-11 11:08 ` Andrea Righi
2009-04-11 15:04 ` Andrea Righi
[not found] ` <20090411150359.GA8265@linux>
2009-04-11 18:21 ` Andrew Morton
2009-04-11 19:32 ` Andrea Righi
2009-04-13 23:34 ` Andreas Schwab
[not found] ` <20090417182507.0bd85ccc.krzysztof.h1@poczta.fm>
2009-04-17 22:51 ` Andrea Righi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090410220521.GB21294@linux \
--to=righi.andrea@gmail.com \
--cc=adaplas@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arvidjaar@gmail.com \
--cc=davej@redhat.com \
--cc=eric.y.miao@gmail.com \
--cc=geert@linux-m68k.org \
--cc=hannes@cmpxchg.org \
--cc=harvey.harrison@gmail.com \
--cc=krzysztof.h1@poczta.fm \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=rjw@sisk.pl \
--cc=stefanr@s5r6.in-berlin.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).