linux-kernel - Re: [PATCH] fb: Rework locking to fix lock ordering on takeover

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]

Date:	Fri, 4 Jan 2013 13:25:57 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Alexander Holler <holler@...oftware.de>
Cc:	Borislav Petkov <bp@...en8.de>, Shawn Guo <shawn.guo@...aro.org>,
	Sasha Levin <levinsasha928@...il.com>,
	Cong Wang <xiyou.wangcong@...il.com>,
	Josh Boyer <jwboyer@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Tobias Schandinat <florianSchandinat@....de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-fbdev@...r.kernel.org, Bernie Thompson <bernie@...gable.com>,
	Steve Glendinning <steve.glendinning@...well.net>,
	Dave Airlie <airlied@...hat.com>
Subject: Re: [PATCH] fb: Rework locking to fix lock ordering on takeover

On Fri, 04 Jan 2013 13:50:37 +0100
Alexander Holler <holler@...oftware.de> wrote:

> Am 28.12.2012 13:40, schrieb Borislav Petkov:
> > On Fri, Dec 28, 2012 at 07:50:27PM +0800, Shawn Guo wrote:
> >> +1
> >>
> >> http://thread.gmane.org/gmane.linux.kernel/1413953/focus=1415070
> >
> > Cool, works fine here too. Is Linus on CC? (/me checks.. ) Yes he is,
> > good.
> >
> > Linus, Alan's patch works at least in 2 cases, you might consider
> > picking it up directly since the fb maintainer is absent, reportedly.
> 
> 
> Btw. I think all the usb-fb's (udlfb, smscufx and udl) are broken, at 
> least on ARM(v5). When I have linked in udlfb the following happens on 
> boot (with an attached USB-LCD and with or without the "Rework locking 
> patch):

They are broken if used as the system console (has been known for years).
Perhaps your x86 test has the system console still on another device ?

For the udl layer it shouldn't matter as Dave Airlie wrote a DRM driver
for udl which obsoletes the old fb layer one and works much better
(although the error handling is still totally broken and leaks like a
sieve if it fails)

Fixing the console isn't that difficult - you just need to make your
device queue the console I/O to a worker thread of some kind. We don't
want to do that by default because we want to get the messages out
reliably and immediately on saner hardware. Given there are several
such cases a general helper and a console "I am crap" flag might be better
than hacking each driver.

Alan

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