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] [day] [month] [year] [list]

Date:	Tue, 30 Jun 2015 08:36:58 +0200
From:	Daniel Vetter <daniel.vetter@...ll.ch>
To:	Rui Wang <rui.y.wang@...el.com>
Cc:	Borislav Petkov <bp@...en8.de>, "Luck, Tony" <tony.luck@...el.com>,
	Dave Airlie <airlied@...hat.com>,
	"Clark, Rob" <robdclark@...il.com>,
	Matthew D Roper <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 Tue, Jun 30, 2015 at 4:53 AM, Rui Wang <rui.y.wang@...el.com> wrote:
> On Monday, June 29, 2015 5:25 PM, Daniel Vetter <daniel.vetter@...ll.ch> wrote:
>> 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.
>
> I think testing can be done by injecting a fatal machine check exception
> via einj's debugfs interface. I can reproduce the hard hang every time.
> I think It can be a simple script or C program do to the automated testing.
> If anyone has any patch I'll be happy to help test it out.

Testing shouldn't kill the machine ;-)

The idea I had is to just exercise the drm panic code (since we'd need
to shunt everything else), and that can be done my calling the
relevant functions from a hardirq context. And hardirq context is
simples to get with a IPI to the local cpu. This way we don't depend
upon the entire panic path to be recoverable, but only upon the drm
bits being sane.

The other thing that needs testing is pushing all the fbdev callbacks
into workers if run from non-process context. But that's something
fbdev likes doing anyway (it's just that most drivers don't need to
overwrite the hooks where this usually happens).
-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/