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: <CAKMK7uGbT6LYW5+75sowtJ95yitTTUbwRFhuWqeGKJNAUDY7kg@mail.gmail.com>
Date:	Tue, 16 Dec 2014 16:10:12 +0100
From:	Daniel Vetter <daniel.vetter@...ll.ch>
To:	Peter Hurley <peter@...leysoftware.com>
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 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).

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).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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/