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

[Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>]

On 2018/09/24 17:11, Tetsuo Handa wrote:
> On 2018/09/19 20:02, Tetsuo Handa wrote:
>> On 2018/09/14 21:22, Sergey Senozhatsky wrote:
>>> The "SMP-safe" comment becomes a bit tricky when pr_line is used with a
>>> static buffer. Either we need to require synchronization - umm... and
>>> document it - or to provide some means of synchronization in pr_line().
>>> Let's think what pr_line API should do about it.
>>>
>>> Any thoughts?
>>>
>>
>> I'm inclined to propose a simple one shown below, similar to just having
>> several "struct cont" for concurrent printk() users.
>> What Linus has commented is that implicit context is bad, and below one
>> uses explicit context.
>> After almost all users are converted to use below one, we might be able
>> to get rid of KERN_CONT support.
> 
> The reason of using statically preallocated global buffers is that I think
> that it is inconvenient for KERN_CONT users to calculate necessary bytes
> only for avoiding message truncation. The pr_line might be passed to deep
> into the callchain and adjusting buffer size whenever the content's possible
> max length changes is as much painful as changing printk() to accept only
> one "const char *" argument. Even if we guarantee that any context can
> allocate buffer from kernel stack, we cannot guarantee that many concurrent
> printk() won't trigger lockup. Thus, I think that trying to allocate from
> finite static buffers with a fallback to unbuffered printk() upon failure
> is sufficient.
> 

Hmm, what problem is blocking this topic?

I think that the SMP-safe comment is unnecessary for line buffered printk() API.
What we want to do is to avoid mixing incomplete lines from concurrent printk()
callers (and then, prefix caller's information in order to help grouping multiple
lines) rather than avoid stalls / crashes / lost messages caused by concurrent
printk() callers.

We could avoid crashes if there is no bug in printk() related code. But we can
never avoid stalls / lost messages as long as we floodly call printk(). Even if
line buffered printk() API were SMP-safe, printk() might have to discard the
output. We need to try to avoid too much printk() - as if there is no concept
of SMP-safeness regardless of whether pr_line() is used with a static buffer.

Therefore, I think that "Either we need to require synchronization - umm... and
document it - or to provide some means of synchronization in pr_line()." is a
pointless worry. It is only existing printk() API which needs synchronization. I
think that line buffered printk() API does not need to talk about synchronization.
Just saying "don't share DEFINE_PR_LINE()/DEFINE_PR_LINE_BUF() variables" will be
sufficient.