Re: printk meeting at LPC

From: John Ogness <john.ogness@linutronix.de>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Petr Mladek <pmladek@suse.com>,
	Andrea Parri <parri.andrea@gmail.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Sergey Senozhatsky <sergey.senozhatsky.work@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: Sun, 15 Sep 2019 15:47:26 +0200	[thread overview]
Message-ID: <87d0g18ydt.fsf@linutronix.de> (raw)
In-Reply-To: <CAKMK7uHXTGKSyXgUOucNr4HSrcnBxVkkoqA=VzF4-=sZSq1MKw@mail.gmail.com> (Daniel Vetter's message of "Fri, 13 Sep 2019 16:48:48 +0200")

On 2019-09-13, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> 2. A kernel thread will be created for each registered console, each
>> responsible for being the sole printers to their respective
>> consoles. With this, console printing is _fully_ decoupled from
>> printk() callers.
>
> Is the plan to split the console_lock up into a per-console thing? Or
> postponed for later on?

AFAICT, the only purpose for a console_lock would be to synchronize
between the console printing kthread and some other component that wants
to write to that same device. So a per-console console_lock should be
the proper solution. However, I will look into the details. My main
concerns about this are the suspend/resume logic and the code sitting
behind /dev/console. I will share details once I've sorted it all out.

>> 6. A new may-sleep function pr_flush() will be made available to wait
>> for all previously printk'd messages to be output on all consoles
>> before proceeding. For example:
>>
>>     pr_cont("Running test ABC... ");
>>     pr_flush();
>>
>>     do_test();
>>
>>     pr_cont("PASSED\n");
>>     pr_flush();
>
> Just crossed my mind: Could/should we lockdep-annotate pr_flush (take
> a lockdep map in there that we also take around the calls down into
> console drivers in each of the console printing kthreads or something
> like that)? Just to avoid too many surprises when people call pr_flush
> from within gpu drivers and wonder why it doesn't work so well.

Why would it not work so well? Basically the task calling pr_flush()
will monitor the lockless iterators of the various consoles until _all_
have hit/passed the latest sequence number from the time of the call.

> Although with this nice plan we'll take the modeset paths fully out of
> the printk paths (even for normal outputs) I hope, so should be a lot
> more reasonable.

You will be running in your own preemptible kthread, so any paths you
take should be safe.

> From gpu perspective this all sounds extremely good and first
> realistic plan that might lead us to an actually working bsod on
> linux.

Are you planning on basing the bsod stuff on write_atomic() (which is
used after entering an emergency state) or on the kmsg_dump facility? I
would expect kmsg_dump might be more appropriate, unless there are
concerns that the machine will die before getting that far (i.e. there
is a lot that happens between when an OOPS begins and when kmsg_dumpers
are invoked).

John Ogness