linux-kernel - Re: [PATCH v4 3/3] vt: fix console lock vs. kernfs s

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: <5490545A.7020605@hurleysoftware.com>
Date:	Tue, 16 Dec 2014 10:48:42 -0500
From:	Peter Hurley <peter@...leysoftware.com>
To:	Daniel Vetter <daniel.vetter@...ll.ch>
CC:	Imre Deak <imre.deak@...el.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 3/3] vt: fix console lock vs. kernfs s_active lock
 order

On 12/16/2014 10:10 AM, Daniel Vetter wrote:
> On Tue, Dec 16, 2014 at 4:00 PM, Peter Hurley <peter@...leysoftware.com> wrote:
>>> The fix will be anyway the same in principal even after Daniel's planned
>>> rework for fbcon/fbdev: not holding the console_lock while freeing the
>>> sysfs entries.
>>
>> Oh, I didn't know Daniel was planning to rework fbcon/fbdev.
> 
> I don't. I've tried, cried and failed, so maybe in my next live ;-)
> But what I've tried was "let's fix fbcon" which was probably a bit too
> ambigitous. Splitting the notifier chains should be a lot more doable
> (but still lots of work I guess). The problem is it's not just the
> notifier chain that's broken with fbcon, but a lot more things:
> - initial modeset is done while holding the console lock. Would be
> true even after we fix this, since it's done as part of the con setup
> done by con_register. We'd need to do the modeset upfront, before
> registering fbcon.
> - panic handling is a joke with drm drivers and fbdev emulation plus
> fbcon - there's way too many sleeps and way too much code in the
> fbcon+drm panic path for this to ever work reliably as is. Would need
> massive rework. One of the most glaring things is that we have about 3
> things that tried to set up fbcon on panic (drm fbdev emulation panic
> handler, console unblanking on panic and fbcon panic handling).

yep - vt + printk + console lock + fbcon/fbdev + drm helper + kms driver
is a total nightmare.

> It's imo unfixable overall, so my long term plan is to get rid of
> fbdev emulation, fbcon and all console_lock paths from kms drivers (we
> have that now with I915_FBDEV=n). And then provide consoles with
> userspace deamons (kmscon) and a very minimalistic crash-dump tooling
> for panic handling on bare-bones kms drivers (not yet there, but
> patches from David Herrmann are floating around).

Interesting, I'll have to look into that.

Regards,
Peter Hurleykmscon

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