On Wed 2017-08-30 11:47:03, Sergey Senozhatsky wrote:
> On (08/29/17 19:31), Joe Perches wrote:
> [..]
> > > the idea is not to do printk() on that seq buffer at all, but to
> > > log_store(), atomically, seq buffer messages
> > >
> > > spin_lock(&logbuf_lock)
> > > while (offset < seq_buffer->len) {
> > > ...
> > > log_store(seq->buffer + offset);
> > > ...
> > > }
> > > spin_unlock(&logbuf_unlock)
> >
> > Why?
>
> Tetsuo wants this, for instance,
> for OOM reports and backtraces. SCIS/ATA people want it as well.
The mixing of related lines might cause problems. But I am not sure
if it can be fixed a safe way on the printk side. Especially I am
afraid of an extensive buffering.
My underestanding, of the discussion about printk kthread patchset,
is that printk() has the following priorities:
1. do not break the system (deadlock, livelock, softlock)
2. get the message out (suddent death, panic, flood of messages)
3. keep the message readable (cont lines, related lines)
Any buffering would delay showing the message. It increases
the risk that nobody will see it at all. It is acceptable
in printk_safe() and printk_safe_nmi() because we did not
find a better way to avoid the deadlock. But I am not sure
about any buffering used for a better readability. It is
against the priorities mentioned above.
Well, the buffering might be acceptable for single lines. I mean
to solve KERN_CONT problems. A good API might allow to get rid
of KERN_CONT, and the unreliable and rather complex code around
struct cont in kernel/printk/printk.c.
I would be afraid of adding an API that would allow to
(transparently) redirect printing into a buffer from a huge
amount of code.
Alternative solution would be to print more information
per-line, for example:
<timestamp> <PID> <context> message
Then you might extract the related lines using a simple
grep. It would be similar to the output of
strace -f -t -o <log> <command>.
Best Regards,
Petr
