All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Stefano Brivio <stefano.brivio@polimi.it>,
	Robert Love <rml@tech9.net>,
	linux-kernel@vger.kernel.org, Dave Jones <davej@redhat.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, Michael Buesch <mb@bu3sch.de>,
	Thomas Gleixner <tglx@linutronix.de>, Len Brown <lenb@kernel.org>
Subject: Re: [PATCH] scheduler: fix x86 regression in native_sched_clock
Date: Fri, 7 Dec 2007 12:07:25 +0100	[thread overview]
Message-ID: <20071207110725.GA8256@elte.hu> (raw)
In-Reply-To: <20071207104013.GC27307@elte.hu>


* Ingo Molnar <mingo@elte.hu> wrote:

> > > -				t = printk_clock();
> > > +				t = cpu_clock(printk_cpu);
> > >  				nanosec_rem = do_div(t, 1000000000);
> > >  				tlen = sprintf(tbuf,
> > >  						"<%c>[%5lu.%06lu] ",
> > 
> > A bit risky - it's quite an expansion of code which no longer can call 
> > printk.
> > 
> > You might want to take that WARN_ON out of __update_rq_clock() ;)
> 
> hm, dont we already detect printk recursions and turn them into a 
> silent return instead of a hang/crash?

ugh, we dont. So i guess the (tested) patch below is highly needed. (If 
such incidents become frequent then we could save the stackdump of the 
recursion via save_stack_trace() too - but i wanted to keep the initial 
code simple.)

	Ingo

---------------->
Subject: printk: make printk more robust by not allowing recursion
From: Ingo Molnar <mingo@elte.hu>

make printk more robust by allowing recursion only if there's a crash
going on. Also add recursion detection.

I've tested it with an artificially injected printk recursion - instead
of a lockup or spontaneous reboot or other crash, the output was a well
controlled:

[   41.057335] SysRq : <2>BUG: recent printk recursion!
[   41.057335] loglevel0-8 reBoot Crashdump show-all-locks(D) tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw Sync showTasks Unmount shoW-blocked-tasks

also do all this printk logic with irqs disabled.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 kernel/printk.c |   52 ++++++++++++++++++++++++++++++++++++++++++----------
 1 file changed, 42 insertions(+), 10 deletions(-)

Index: linux/kernel/printk.c
===================================================================
--- linux.orig/kernel/printk.c
+++ linux/kernel/printk.c
@@ -623,30 +623,57 @@ asmlinkage int printk(const char *fmt, .
 /* cpu currently holding logbuf_lock */
 static volatile unsigned int printk_cpu = UINT_MAX;
 
+const char printk_recursion_bug_msg [] =
+			KERN_CRIT "BUG: recent printk recursion!\n";
+static int printk_recursion_bug;
+
 asmlinkage int vprintk(const char *fmt, va_list args)
 {
+	static int log_level_unknown = 1;
+	static char printk_buf[1024];
+
 	unsigned long flags;
-	int printed_len;
+	int printed_len = 0;
+	int this_cpu;
 	char *p;
-	static char printk_buf[1024];
-	static int log_level_unknown = 1;
 
 	boot_delay_msec();
 
 	preempt_disable();
-	if (unlikely(oops_in_progress) && printk_cpu == smp_processor_id())
-		/* If a crash is occurring during printk() on this CPU,
-		 * make sure we can't deadlock */
-		zap_locks();
-
 	/* This stops the holder of console_sem just where we want him */
 	raw_local_irq_save(flags);
+	this_cpu = smp_processor_id();
+
+	/*
+	 * Ouch, printk recursed into itself!
+	 */
+	if (unlikely(printk_cpu == this_cpu)) {
+		/*
+		 * If a crash is occurring during printk() on this CPU,
+		 * then try to get the crash message out but make sure
+		 * we can't deadlock. Otherwise just return to avoid the
+		 * recursion and return - but flag the recursion so that
+		 * it can be printed at the next appropriate moment:
+		 */
+		if (!oops_in_progress) {
+			printk_recursion_bug = 1;
+			goto out_restore_irqs;
+		}
+		zap_locks();
+	}
+
 	lockdep_off();
 	spin_lock(&logbuf_lock);
-	printk_cpu = smp_processor_id();
+	printk_cpu = this_cpu;
 
+	if (printk_recursion_bug) {
+		printk_recursion_bug = 0;
+		strcpy(printk_buf, printk_recursion_bug_msg);
+		printed_len = sizeof(printk_recursion_bug_msg);
+	}
 	/* Emit the output into the temporary buffer */
-	printed_len = vscnprintf(printk_buf, sizeof(printk_buf), fmt, args);
+	printed_len += vscnprintf(printk_buf + printed_len,
+				  sizeof(printk_buf), fmt, args);
 
 	/*
 	 * Copy the output into log_buf.  If the caller didn't provide
@@ -675,6 +702,10 @@ asmlinkage int vprintk(const char *fmt, 
 					loglev_char = default_message_loglevel
 						+ '0';
 				}
+				if (panic_timeout) {
+					panic_timeout = 0;
+					printk("recurse!\n");
+				}
 				t = cpu_clock(printk_cpu);
 				nanosec_rem = do_div(t, 1000000000);
 				tlen = sprintf(tbuf,
@@ -739,6 +770,7 @@ asmlinkage int vprintk(const char *fmt, 
 		printk_cpu = UINT_MAX;
 		spin_unlock(&logbuf_lock);
 		lockdep_on();
+out_restore_irqs:
 		raw_local_irq_restore(flags);
 	}
 

  reply	other threads:[~2007-12-07 11:08 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-07  1:19 [PATCH] scheduler: fix x86 regression in native_sched_clock Stefano Brivio
2007-12-07  5:29 ` Nick Piggin
2007-12-07  5:51 ` Thomas Gleixner
2007-12-07  7:18   ` Guillaume Chazarain
2007-12-07  8:02     ` Guillaume Chazarain
2007-12-07  8:51       ` Ingo Molnar
2007-12-07  9:29         ` Guillaume Chazarain
2007-12-07  9:59           ` Ingo Molnar
2007-12-07 13:55       ` [patch] x86: scale cyc_2_nsec according to CPU frequency Ingo Molnar
2007-12-07 14:27         ` Guillaume Chazarain
2007-12-07 14:52           ` Ingo Molnar
2007-12-08 15:57             ` Arjan van de Ven
2007-12-08 19:16               ` Ingo Molnar
2007-12-08 20:18                 ` Arjan van de Ven
2007-12-07 10:37   ` [PATCH] scheduler: fix x86 regression in native_sched_clock Andi Kleen
2007-12-07  8:45 ` Ingo Molnar
2007-12-07 10:32   ` Andrew Morton
2007-12-07 10:40     ` Ingo Molnar
2007-12-07 11:07       ` Ingo Molnar [this message]
2007-12-07 11:09       ` Andrew Morton
2007-12-07 11:12         ` Ingo Molnar
2007-12-07 11:13   ` Nick Piggin
2007-12-07 11:17     ` Ingo Molnar
2007-12-07 16:48       ` Nick Piggin
2007-12-08  0:50         ` Nick Piggin
2007-12-08  0:57           ` Nick Piggin
2007-12-08  8:52             ` Ingo Molnar
2007-12-08 23:37               ` Guillaume Chazarain
2007-12-12  4:42               ` Nick Piggin
2007-12-12 10:44                 ` Ingo Molnar
2007-12-07 11:18     ` Guillaume Chazarain
2007-12-07 11:57       ` Guillaume Chazarain
2007-12-07 11:23     ` stefano.brivio
2007-12-07 12:11       ` Ingo Molnar
2007-12-07 12:25       ` Ingo Molnar
2007-12-07 12:35         ` Ingo Molnar
2007-12-07 12:40           ` Ingo Molnar
2007-12-07 14:54             ` Ingo Molnar
2007-12-07 16:46               ` Guillaume Chazarain
2007-12-07 17:57                 ` Ingo Molnar
2007-12-08 15:06                   ` Mark Lord
2007-12-08 15:13                     ` Ingo Molnar
2007-12-08 15:27                       ` Michael Buesch
2007-12-08 15:33                         ` Ingo Molnar
2007-12-08 15:36                           ` Michael Buesch
2007-12-08 15:41                             ` Ingo Molnar
2007-12-07 11:24     ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071207110725.GA8256@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=davej@redhat.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mb@bu3sch.de \
    --cc=rjw@sisk.pl \
    --cc=rml@tech9.net \
    --cc=stefano.brivio@polimi.it \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.