linux-kernel - Re: [PATCH] printk: Don't discard earlier unprinted messages to make space

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 23 Oct 2015 10:49:01 +0200
From:	Petr Mladek <pmladek@...e.com>
To:	David Howells <dhowells@...hat.com>
Cc:	linux-kernel@...r.kernel.org, jack@...e.cz, will.deacon@....com,
	rostedt@...dmis.org, dwmw2@...radead.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] printk: Don't discard earlier unprinted messages to make
 space

On Thu 2015-10-22 14:19:26, David Howells wrote:
> Petr Mladek <pmladek@...e.com> wrote:
> 
> > I would expect that the first few messages are printed to the console
> > before the buffer is wrapped. IMHO, in many cases, you are interested
> > into the final messages that describe why the system went down.
> 
> The last message might tell you that the machine panicked because the NMI
> handler triggered due to a spinlocked section taking too long or something.
> This doesn't help if the oops that caused the spinlock to remain held or
> whatever gets discarded from the buffer due to several intervening complaints
> that result secondarily from the initial oops.

There might be flood of messages if you enable debugging or so. In
this case, the interesting messages would be at the end of the buffer.

IMHO, you want both the beginning of the flood and the end when
machine goes down. You do not want the repeated blob in the middle.
Do you really miss the first few lines on the serial console, please?
Did you consider the panic on Oops kernel parameter?

> > If there is no time to print them, you want to have them in the crash dump
> > (ring buffer) at least.
>
> But not at the expense of discarding the first oops report.  *That* one is the
> most important.

But your patch discards the initial messages as well once they are printed.

> Perhaps things could be arranged such that messages *can* be discarded from
> the front of the buffer *provided* they are not oops messages.

Another possibility would be to decide this by the importance level
of the message. For example, we might start ignoring less important
messages when the buffer is getting full. But this should be optional.
It makes sense only when someone print/logs the messages somewhere.

Anyway, be warned that any additional complexity must have very good
reasons. The printk code already is bloated and there is a strong
resistance to make it worse.

Best Regards,
Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/