linux-kernel - Re: drm/mgag200: doesn't work in panic context

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: <CAKMK7uFuN1MP7=HW7VOTefnHLRsRYBh5i+pmdqug9sO6d5KXqA@mail.gmail.com>
Date:	Mon, 29 Jun 2015 11:25:17 +0200
From:	Daniel Vetter <daniel.vetter@...ll.ch>
To:	Borislav Petkov <bp@...en8.de>
Cc:	"Luck, Tony" <tony.luck@...el.com>,
	"Wang, Rui Y" <rui.y.wang@...el.com>,
	Dave Airlie <airlied@...hat.com>,
	"Clark, Rob" <robdclark@...il.com>,
	"Roper, Matthew D" <matthew.d.roper@...el.com>,
	"Chen, Gong" <gong.chen@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: drm/mgag200: doesn't work in panic context

On Mon, Jun 29, 2015 at 10:09 AM, Borislav Petkov <bp@...en8.de> wrote:
> On Sat, Jun 27, 2015 at 07:56:19PM +0200, Daniel Vetter wrote:
>
> <snip very useful explanation for !GPU people>
>
>> Which could all happen very much after the kernel made it's dying
>> sigh. Display hw has long stopped being this simple and display
>> drivers also.
>
> Thanks for the explanation. I was fearing that it would go in such
> direction though. :\ Oh well.
>
> So there are two observations to be ventured here:
>
> * there's still no robust and simple way to save/show oops messages on
> laptops. When a laptop crashes and the user has only this one machine,
> catching the oops can be a serious PITA. Laptop most likely doesn't have
> serial, modeset is hard to do, as you explained, and saving it into
> persistent storage (UEFI) might brick it in some cases or whatever the
> firmware will do to it. I guess we can keep wishing here for something
> better.

As long as the display is up and running we should have a fair stab at
showing the oops - it's just that no one has seriously bothered with
the necessary infastructure, automated testing (it won't work
otherwise) and driver work.

> * The server aspect might not really need GPU modesetting IMHO because
> realistically, servers have serial so the oops can go out there. Which
> begs the other question:
>
> Shouldn't drm_fb_helper_panic() and that path below it simply be
> removed?
>
> I mean, if it needs to do all that hw-reconf on the panic path and if
> that reconfiguration is not completely reliable, maybe we shouldn't do
> it all?
>
> This way, we will basically remain as quiet as possible in order not
> to muddle the system unreasonably when we're about to die and the only
> thing we want to catch is an oops or maybe kexec the crash kernel...
>
> Oops will go out on serial anyway and server will kexec - GPU/fb stuff
> doesn't do anything. Yes, no?

drm_fb_helper_panic isn't the only panic handler - fbdev/fbcon have
their own. They interfere, and fbdev blissfully assumes that it can
call almost any driver hook from hardirq context. Which means you'd
also need to consolidate the various hand-rolled (in drivers instead
of the fbdev helper) bits to offload fbdev callbacks to workers and
make sure we don't go boom in panics in there either.

It's really a big mess unfortunately :(
-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/