From: Peter Hurley <peter@hurleysoftware.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Imre Deak <imre.deak@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jslaby@suse.cz>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 3/3] vt: fix console lock vs. kernfs s_active lock order
Date: Tue, 16 Dec 2014 10:48:42 -0500 [thread overview]
Message-ID: <5490545A.7020605@hurleysoftware.com> (raw)
In-Reply-To: <CAKMK7uGbT6LYW5+75sowtJ95yitTTUbwRFhuWqeGKJNAUDY7kg@mail.gmail.com>
On 12/16/2014 10:10 AM, Daniel Vetter wrote:
> On Tue, Dec 16, 2014 at 4:00 PM, Peter Hurley <peter@hurleysoftware.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
next prev parent reply other threads:[~2014-12-16 15:48 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-15 22:15 [PATCH v4 1/3] vt: fix check for system/busy console drivers when unregistering them Imre Deak
2014-12-15 22:16 ` [PATCH v4 2/3] vt: fix locking around vt_bind/vt_unbind Imre Deak
2014-12-16 7:37 ` Daniel Vetter
2014-12-15 22:16 ` [PATCH v4 3/3] vt: fix console lock vs. kernfs s_active lock order Imre Deak
2014-12-16 7:53 ` Daniel Vetter
2014-12-16 10:23 ` Imre Deak
2014-12-16 12:50 ` Peter Hurley
2014-12-16 13:45 ` Daniel Vetter
2014-12-16 14:38 ` Imre Deak
2014-12-16 15:00 ` Peter Hurley
2014-12-16 15:10 ` Daniel Vetter
2014-12-16 15:48 ` Peter Hurley [this message]
2014-12-16 16:22 ` Imre Deak
2014-12-16 17:15 ` Peter Hurley
2014-12-16 17:42 ` Daniel Vetter
2015-03-26 19:59 ` Jesse Barnes
2015-03-26 21:01 ` Greg Kroah-Hartman
2015-03-26 21:05 ` Imre Deak
2015-03-27 7:46 ` Daniel Vetter
2015-03-31 15:59 ` Greg Kroah-Hartman
2015-04-01 18:06 ` [PATCH] " Imre Deak
2014-12-16 7:35 ` [PATCH v4 1/3] vt: fix check for system/busy console drivers when unregistering them Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5490545A.7020605@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--cc=daniel.vetter@ffwll.ch \
--cc=gregkh@linuxfoundation.org \
--cc=imre.deak@intel.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.