linux-kernel - Re: [PATCH] fbmem: fix race condition between register_framebuffer() and fb

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: <20110525205707.12abc68c@neptune.home>
Date:	Wed, 25 May 2011 20:57:07 +0200
From:	Bruno Prémont <bonbons@...ux-vserver.org>
To:	Fabio Erculiani <lxnay@...ayon.org>
Cc:	linux-fbdev@...r.kernel.org, lethal@...ux-sh.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fbmem: fix race condition between
 register_framebuffer() and fb_open()

On Wed, 25 May 2011 Fabio Erculiani <lxnay@...ayon.org> wrote:
> On Wed, May 25, 2011 at 8:46 PM, Bruno Prémont wrote:
> > On Wed, 25 May 2011 Fabio Erculiani <lxnay@...ayon.org> wrote:
> >> I'm not a fbdev expert. So I leave the real fix to real men ( ;-) ).
> >> It is causing deadlock during boot, so I would consider it quite critical.
> >> Users using any fb driver will get into troubles.
> >> The workaround is to boot with vga=normal.
> >
> > What is your system doing during boot? I've never seen it here but maybe
> > my boot sequence is too simple.
> 
> I'm using vesafb and vga=791. It is quite simple to reproduce.
> Also see: http://bugs.gentoo.org/show_bug.cgi?id=368109

Looks like gentoo kernel, might be splash is related to the hang

> > Could you tell if it deadlocks before init gets started or afterwards,
> > which fb drivers (and extra kernel patches if any) are in use.
> 
> Exactly when register_framebuffer() is called, in my case, early in
> the boot phase, before init.
> 
> >
> > If you have the complete backtrace of the deadlocked processes it would
> > help getting a better idea of what is affected and how (and why just the
> > framebuffer's lock is not causing trouble with earlier kernel versions).
> 
> Because that code got a HUGE rewrite in the latest cycle, where
> registration_lock has been introduce.
> Just make a diff between 2.6.38 and 2.6.39. It will be easy to see
> that SO MANY lines have changed ;-)
> Anyway, since I'm out of office these days, I won't be able to send
> you the traceback this week, but since so many people have run into
> it, I guess it's fairly simple to reproduce.

Rewrite was not so huge, and I'm not affected here (running with KMS
compiled in though and vanilla kernel).
Probably the cause is related to one of the extra patches provided by
Gentoo and subscribing to framebuffer registration notifications.

Will have a look.

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