linux-kernel - Re: [PATCH 2/2] printk: always report lost messages on serial console

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170109165623.GE20785@pathway.suse.cz>
Date:   Mon, 9 Jan 2017 17:56:23 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Peter Hurley <peter@...leysoftware.com>,
        linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: [PATCH 2/2] printk: always report lost messages on serial console

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