Re: [PATCH 2/2] printk: always report lost messages on serial console
From: Petr Mladek
Date: Mon Jan 09 2017 - 11:56:31 EST
On Sat 2016-12-24 23:09:02, Sergey Senozhatsky wrote:
> The "printk messages dropped" report is 'attached' to a kernel
> message located at console_idx offset. This does not work well
> if we skip that message due to loglevel filtering, because in
> this case we also skip/lose dropped message report.
>
> Disable suppress_message_printing() loglevel filtering if we
> must report "printk messages dropped" condition.
I have looked at this once again. Please, do you have a real-life
example when the "printk messages dropped" was not printed?
I ask because the original code looks like this this:
if (console_seq < log_first_seq) {
<store warning into "text" buffer>
console_seq = log_first_seq;
console_idx = log_first_idx;
skip:
if (console_seq == log_next_seq)
break;
msg = log_from_idx(console_idx);
if (suppress_message_printing(msg->level)) {
console_idx = log_next(console_idx);
console_seq++;
goto skip;
}
<add visible messsage into "text" buffer>
console_idx = log_next(console_idx);
console_seq++;
raw_spin_unlock(&logbuf_lock);
<push "text" buffer to console>
By other words, the search for a visible message is finished when
we find one or when the entire log buffer is checked.
As a consequence, the warning about "printk messages dropped" is
lost _only_ when there was no visible message in the entire buffer.
Therefore, the warning might get lost only when the log buffer
was very small or when console_level filter was too restricting.
I wonder if this is a case for a real user or a real life.
In each case, such a scenario most likely comes from a very
curious setup.
It is possible that your fix is fine. If we lose messages,
we are screwed anyway. But I still have problems to accept
that we would start printing less important messages (that would
normally be ignored) in situation when we have troubles
to print the more important ones. This logic rings warning
bells in my head and this is why I suggest more conservative
solution and ask the many questions.
Am I so wrong in my thinking, please?
Best Regards,
Petr