Re: printk meeting at LPC

From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Petr Mladek <pmladek@suse.com>,
	Andrea Parri <parri.andrea@gmail.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Brendan Higgins <brendanhiggins@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Theodore Ts'o" <tytso@mit.edu>, Paul Turner <pjt@google.com>,
	Prarit Bhargava <prarit@redhat.com>
Subject: Re: printk meeting at LPC
Date: Thu, 19 Sep 2019 10:06:44 +0200	[thread overview]
Message-ID: <CAKMK7uH1Nz5+-oA06KmRzWvM+KcKZY4GnJOdQurFrXLc4k5h7Q@mail.gmail.com> (raw)
In-Reply-To: <87h85anj85.fsf@linutronix.de>

On Wed, Sep 18, 2019 at 9:42 AM John Ogness <john.ogness@linutronix.de> wrote:
>
> On 2019-09-18, Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:
> >> For instance, tty/sysrq must be able to switch printk emergency
> >> on/off.
> >
> > How did we come up to that _sync() printk() emergency mode (when we
> > make sure that there is no active printing kthread)? We had a number
> > of cases (complaints) of lost kernel messages. There are scenarios in
> > which we cannot offload to async preemptible printing kthread, because
> > current control path is, for instance, going to reboot the kernel. In
> > sync printk() mode we have some sort (!) of guarantees that when we do
> >
> >               pr_emerg("Restarting system\n");
> >               kmsg_dump(KMSG_DUMP_RESTART);
> >               machine_restart(cmd);
> >
> > pr_emerg("Restarting system\n") is going to flush logbuf before the
> > system will machine_restart().
>
> Yes, this was why I asked Daniel how the bsod stuff will be
> implemented. We don't want a bsod just because we are
> restarting. Perhaps write_atomic() should also have a "reason" argument
> like kmsg_dump does. I will keep in touch with Daniel to make sure we
> are sync on this.

I thought that's why there'll be the oops_in_progress parameter for
write_atomic?

For the fbcon/graphics side I think we maybe need three levels:

- normal console writes with the kthread
- write_atomic, but non-destructive: Just directly write into the
framebuffer. Might need a serious locking rework in fbcon to make this
possible, plus won't work on drivers where the framebuffer is either
not statically pinned, or where you need to take additional work to
flush the updates out to the display.
- bsod, where we attempt an unfriendly takeover of the display with
trylocks and just overwrite what's there to display the oops. that one
is probably best suited for kmsg_dump.

Cheers, Daniel

> > It's going to be a bit harder when we have per-console kthread.
>
> Each console has its own iterator. This iterators will need to advance,
> regardless if the message was printed via write() or write_atomic().
>
> John Ogness

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch