linux-kernel - Re: [REGRESSION] commit 66c1ca0: {fbmem: fix fb_info->lock and mm->mmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090410222122.87be60f6.krzysztof.h1@poczta.fm>
Date:	Fri, 10 Apr 2009 22:21:22 +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 Thu, 9 Apr 2009 14:58:51 +0200
Andrea Righi <righi.andrea@...il.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().

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).

I'll try to prepare a patch after the Easters. This will require a revert
 of the 66c1ca commit.

Happy Easters,
Krzysztof

----------------------------------------------------------------------
Nagrody w jednym miejscu!
Sprawdz >> http://link.interia.pl/f210b

--
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/