linux-kernel - [RFC PATCH 07/11] printk: right ordering of the cont buffers from NMI context

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]

Date:	Fri,  9 May 2014 11:11:01 +0200
From:	Petr Mladek <pmladek@...e.cz>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Dave Anderson <anderson@...hat.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Kay Sievers <kay@...y.org>, Jiri Kosina <jkosina@...e.cz>,
	Michal Hocko <mhocko@...e.cz>, Jan Kara <jack@...e.cz>,
	linux-kernel@...r.kernel.org, Petr Mladek <pmladek@...e.cz>
Subject: [RFC PATCH 07/11] printk: right ordering of the cont buffers from NMI context

When using the NMI log buffer, continuous messages were sometimes mixed
after merging to the main log buffer.

The problems are solved by the following two tricks. First, continuous messages
are always put into the NMI log buffer if it already contains something. Second,
the main cont buffer is always flushed before merging any message from the NMI
log buffer.

Note that the second part of a continuous message always has to be the first
message in the NMI log buffer. If the first part goes to the main log buffer,
we have the lock for the main log buffer and merge all previous messages.

The only drawback is that we check "nmi_cont" without having "nmi_logbuf_lock".
Well, parallel NMIs are very rare. In fact, they should not happen. In the
worst case, we crate some mess in the log.

I tested this a lot. I still see that a single line might get split into two
lines from time to time. In each case, this patch helped a lot. Especially it
fixed problems with ordering of the line parts.

Signed-off-by: Petr Mladek <pmladek@...e.cz>
---
 kernel/printk/printk.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 12435f3ef2d4..7c992b8f44a4 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1905,6 +1905,7 @@ static void merge_nmi_delayed_printk(void)
 	unsigned long nmi_first_id, nmi_next_id;
 	u32 old_main_next_idx;
 	u64 old_main_next_seq;
+	int main_cont_flushed = 0;
 
 	while (true) {
 		/*
@@ -1917,6 +1918,15 @@ static void merge_nmi_delayed_printk(void)
 		if (likely(nmi_merge_seq == seq_from_id(nmi_next_id)))
 			return;
 
+		/*
+		 * The main cont buffer might include the first part of the
+		 * first message from NMI context.
+		 */
+		if (unlikely(!main_cont_flushed)) {
+			cont_flush(&main_log, LOG_CONT);
+			main_cont_flushed = 1;
+		}
+
 		/* check if we lost some messages */
 		nmi_first_id = ACCESS_ONCE(nmi_log.nmi.first_id);
 		if (nmi_seq_is_invalid(nmi_merge_seq,
@@ -2030,7 +2040,12 @@ asmlinkage int vprintk_emit(int facility, int level,
 	if (likely(!in_nmi())) {
 		raw_spin_lock(&main_logbuf_lock);
 	} else {
-		if (!raw_spin_trylock(&main_logbuf_lock)) {
+		/*
+		 * Always use NMI ring buffer if something is already
+		 * in the cont buffer.
+		 */
+		if ((nmi_cont.len && nmi_cont.owner == current) ||
+		    !raw_spin_trylock(&main_logbuf_lock)) {
 			if (!nmi_log.buf) {
 				lockdep_on();
 				local_irq_restore(flags);
-- 
1.8.4

--
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/