[PATCH v2 1/3] drm: Add support for panic message output

[Daniel Vetter]

On Thu, Mar 14, 2019 at 10:52:08AM +0100, John Ogness wrote:
> On 2019-03-14, John Ogness <john.ogness at linutronix.de> wrote:
> > On 2019-03-14, Daniel Vetter <daniel at ffwll.ch> wrote:
> >> That's why we came up with the trylock + immediate bail out design if
> >> that fails. Plus really only render the oops int whatever is the
> >> current display buffer, so that we don't have to do any hw
> >> programming at all.
> >
> > I think this is your best option. The real work will be identifying
> > any/all spin locking that currently exists. For all of those, the code
> > needs to change to:
> >
> > 1. trylock if oops_in_progress, otherwise spinlock
> 
> On second thought, you shouldn't use oops_in_progress. It would be
> better if DRM had its own flag to signify that it is currently being
> used in kmsg_dump context.

We use oops_in_progress because the fbcon design is a terrible layer cake.
I agree that for the new code we shouldn't use it: New code paths that do
trylock only.

> > 2. if trylock fails, the code must have a sane failure
> >
> > The 2nd point will be the difficult one. For example, you may have
> > functions without a return value taking spinlocks. But now those
> > functions could fail.

Nah, imo no code reuse for the oops path. If you do that you sooner or
later end up pulling in the 100kloc of modeset code, and we've been there.
Doesn't work. New, absolutely minimal oops code, with as little of it
shared with normal kms code.

That's also why we absolutely have to be able to test this stuff without a
real oops.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch