Re: [PATCH] printk: inject caller information into the body of message

[Sergey Senozhatsky]

On (09/28/18 20:21), Tetsuo Handa wrote:
> On 2018/09/28 17:56, Sergey Senozhatsky wrote:
> > The good thing about cont buffer is that we flush it on panic. E.g.
> > core/arch early boot stage can do:
> > 
> > 	pr_cont("going to call early_init_foo()...");
> > 	early_init_foo();
> > 	pr_cont("OK\n");
> > 
> 
> Is printing
> 
>   going to call early_init_foo()...OK
> 
> in one line so critically important?

Could be. If this is the last thing you are about to see on your
serial console. panic_on_flush() is not guaranteed to succeed.

... Hmm. But it seems that this has changed.

We used to flush "incomplete" cont lines (fragments) from console_unlock().

void console_unlock(void)
{
...
        /* flush buffered message fragment immediately to console */
        console_cont_flush(text, sizeof(text));
again:
        for (;;) {
	...
	}
...
}

Unless I'm missing something, we don't anymore.
Since 5c2992ee7fd8a29d04125dc0aa3522784c5fa5eb.
Now we print only log_buf entries. So we either wait for a \n to flush
a complete cont buffer, or for a race to preliminary flush cont buffer.


> > Tetsuo, do you still want to have a fixed size array of printk buffers?
> 
> For my intended users where printk() is used for reporting errors (e.g.
> stack backtrace, GFP_ATOMIC memory allocation failure, lockdep splat),
> being prepared for already tight stack is preferable.

Agreed. A list of printk buffers has some interesting features and may
be we will use it after all.
At the same time the functions you have mentioned can use static char
buffers for pr_line.

> > What do others think?
> 
> Yes, I want to hear from others.

Yep.

	-ss