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: <CAKMK7uF3rvUh9hEr8zC9vV8HL4aHRk-6+Gif7GEW-C5cFWQDuQ@mail.gmail.com>
Date:	Sat, 27 Jun 2015 19:56:19 +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 Sat, Jun 27, 2015 at 4:12 PM, Borislav Petkov <bp@...en8.de> wrote:
> On Sat, Jun 27, 2015 at 03:52:56PM +0200, Daniel Vetter wrote:
>> Hm, what do you mean by fixing this in the allocator? I've made some
>> rough sketch of the problem space in
>> http://www.x.org/wiki/DRMJanitors/ under "Make panic handling work".
>> Problem is that the folks which know what to do (drm hackers) have
>> zero incentive to fix it (since if you blow up a drm driver any kind
>> of fbcon panic handling is hopeless anyway).
>
> Ok, silly question: switching the GPU output to the simplest,
> supported-by-all-GPUs mode before panicking is not that easy too, right?

Anything that resembles doing a modeset (and the precise mode is
totally irrelevant) will be almost impossible: There's clocks to tune,
various links to train, a bunch of sidebind communication and all that
takes time, needs to happen in a very precise order and also needs
lots of mutexes (crossing subsystems sometimes even) to avoid
trampling on maybe the thread that just died and caused the panic.

In short you need specially-written codepaths for panic, which means
only the most minimal thing has a chance to even work. fbdev/fbcon and
the current drm panic handler are anything but that. Doing a full
modeset isn't it either. Heck even the just updating the displayed
buffer might need massive reconfiguration of the memory fetch
watermarks if e.g. the screen is display high bpc yuv and you want to
display the rgb fbcon buffer. And if you'd just try to take what's
currently being displayed there's the annoying problem that often
providing a cpu-contiguous view of that needs a vmalloc area, if not
first moving the buffer around a bit in vram with the copy engine.
That all involves lots of really complex code.

> Or does that mean, one needs to reinit GPU in order to even show
> something...

If the gpu is runtime suspended, then yes you'd get to even init the
entire thing first before you can display anything.

fbdev panic handling was designed for a world where you'd bash a few
values into a few registers and never wait for the CRTC to reach
stable timings and output a useful signal. 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. The only vestige
is that we still call the display pipeline object in drm CRTC for
cathode ray tube controller ...
-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/