On 2018/09/28 18:09, Sergey Senozhatsky wrote: > On (09/24/18 17:11), Tetsuo Handa wrote: >> 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. > > Yes, this makes sense. At the same time we can keep pr_line buffer > in .bss > > static char buffer[1024]; > static DEFINE_PR_LINE_BUF(..., buffer); > > just like you have already mentioned. But that's going to require a > case-by-case handling; so a big list of printk buffers is a simpler > option. Fallback, tho, can be painful. On a system with 1024 CPUs can > one have more than 16 concurrent cont printks? If the answer is yes, > then we are looking at the same broken cont output as before.
I'm OK with making "16" configurable (at kernel configuration and/or at kernel boot like log_buf_len= kernel command line parameter). We could even allow each "struct task_struct" to have corresponding "struct printk_buffer". But if there are such many concurrent callers, the printk() would have already locked up the system to death. ;-)
