Re: [Ksummit-discuss] [TECH TOPIC] asynchronous printk

[Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>]

On (07/19/16 08:17), Hannes Reinecke wrote:
[..]
> Yes. The main problem stems from the fact that printk has two different
> and conflicting use-cases:
> - Really urgent, 'I am about to die' messages. Which obviously need to
>   be printed out as fast as possible.
> - Rather largish, information/logging 'what I always wanted to tell you'
>   type of messages. These messages tend to be very large, but at the end
>   it doesn't really matter _when_ they'll be printed as they are
>   time-stamped anyway.
> 
> For the first use-case you absolutely need a synchronous printk, but
> this is a complete killer for the second case.
> And OTOH having a separate thread is really the way to go for the second
> case, but an absolute no-go for the first.
> 
> So I really wonder if it does make sense to lump both use-cases into one
> call, or whether it wouldn't be better to have two distinct calls
> for that (or, for the sake of argument, use KERN_EMERG to trigger
> synchronous printks).

yes, panic() must be in sync printk mode. but we do it a
bit differently: console_verbose() forces printk to switch
to sync mode.

so panic() goes like this:

	panic()
	{
		console_verbose(); # switch to sync printk. forever.
		bust_spinlocks();
		pr_emerg("Kernel panic - not syncing...");

		....
		debug_locks_off();
		console_flush_on_panic();  # flushes kernel log_bug in
					   # sync mode

		// the rest of panic()

	}

	-ss