* [PATCH] panic: Don't print redundant backtraces on oops
@ 2011-12-08 0:36 Andi Kleen
2011-12-17 0:52 ` Andrew Morton
0 siblings, 1 reply; 4+ messages in thread
From: Andi Kleen @ 2011-12-08 0:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Andi Kleen
From: Andi Kleen <ak@linux.intel.com>
When an oops causes a panic and panic prints another backtrace it's
pretty common to have the original oops data be scrolled away on a 80x50
screen.
The second backtrace is quite redundant and not needed anyways.
So don't print the panic backtrace when oops_in_progress is true.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
kernel/panic.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kernel/panic.c b/kernel/panic.c
index b2659360..398412b 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -78,7 +78,8 @@ NORET_TYPE void panic(const char * fmt, ...)
va_end(args);
printk(KERN_EMERG "Kernel panic - not syncing: %s\n",buf);
#ifdef CONFIG_DEBUG_BUGVERBOSE
- dump_stack();
+ if (!oops_in_progress)
+ dump_stack();
#endif
/*
--
1.7.4.4
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] panic: Don't print redundant backtraces on oops
2011-12-08 0:36 [PATCH] panic: Don't print redundant backtraces on oops Andi Kleen
@ 2011-12-17 0:52 ` Andrew Morton
2011-12-19 14:09 ` Michael Holzheu
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Morton @ 2011-12-17 0:52 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel, Andi Kleen, Michael Holzheu
On Wed, 7 Dec 2011 16:36:43 -0800
Andi Kleen <andi@firstfloor.org> wrote:
> From: Andi Kleen <ak@linux.intel.com>
>
> When an oops causes a panic and panic prints another backtrace it's
> pretty common to have the original oops data be scrolled away on a 80x50
> screen.
>
> The second backtrace is quite redundant and not needed anyways.
>
> So don't print the panic backtrace when oops_in_progress is true.
>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> ---
> kernel/panic.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/panic.c b/kernel/panic.c
> index b2659360..398412b 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -78,7 +78,8 @@ NORET_TYPE void panic(const char * fmt, ...)
> va_end(args);
> printk(KERN_EMERG "Kernel panic - not syncing: %s\n",buf);
> #ifdef CONFIG_DEBUG_BUGVERBOSE
> - dump_stack();
> + if (!oops_in_progress)
> + dump_stack();
> #endif
This is kinda related to Michael's
kdump-fix-crash_kexec-smp_send_stop-race-in-panic.patch, below.
afacit Michael's patch will prevent panic-within-panic, and it does
this by accident becasue we never thought about it. But it won't fix
panic-within-other-oops.
Is there some clever way in which we can satisfy both requirements in
one hit?
From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Subject: kdump: fix crash_kexec()/smp_send_stop() race in panic()
When two CPUs call panic at the same time there is a possible race
condition that can stop kdump. The first CPU calls crash_kexec() and the
second CPU calls smp_send_stop() in panic() before crash_kexec() finished
on the first CPU. So the second CPU stops the first CPU and therefore
kdump fails:
1st CPU:
panic()->crash_kexec()->mutex_trylock(&kexec_mutex)-> do kdump
2nd CPU:
panic()->crash_kexec()->kexec_mutex already held by 1st CPU
->smp_send_stop()-> stop 1st CPU (stop kdump)
This patch fixes the problem by introducing a spinlock in panic that
allows only one CPU to process crash_kexec() and the subsequent panic
code.
All other CPUs call the weak function panic_smp_self_stop() that stops the
CPU itself. This function can be overloaded by architecture code. For
example "tile" can use their lower-power "nap" instruction for that.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Acked-by: Chris Metcalf <cmetcalf@tilera.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/panic.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff -puN kernel/panic.c~kdump-fix-crash_kexec-smp_send_stop-race-in-panic kernel/panic.c
--- a/kernel/panic.c~kdump-fix-crash_kexec-smp_send_stop-race-in-panic
+++ a/kernel/panic.c
@@ -49,6 +49,15 @@ static long no_blink(int state)
long (*panic_blink)(int state);
EXPORT_SYMBOL(panic_blink);
+/*
+ * Stop ourself in panic -- architecture code may override this
+ */
+void __weak panic_smp_self_stop(void)
+{
+ while (1)
+ cpu_relax();
+}
+
/**
* panic - halt the system
* @fmt: The text string to print
@@ -59,6 +68,7 @@ EXPORT_SYMBOL(panic_blink);
*/
void panic(const char *fmt, ...)
{
+ static DEFINE_SPINLOCK(panic_lock);
static char buf[1024];
va_list args;
long i, i_next = 0;
@@ -68,8 +78,14 @@ void panic(const char *fmt, ...)
* It's possible to come here directly from a panic-assertion and
* not have preempt disabled. Some functions called from here want
* preempt to be disabled. No point enabling it later though...
+ *
+ * Only one CPU is allowed to execute the panic code from here. For
+ * multiple parallel invocations of panic, all other CPUs either
+ * stop themself or will wait until they are stopped by the 1st CPU
+ * with smp_send_stop().
*/
- preempt_disable();
+ if (!spin_trylock(&panic_lock))
+ panic_smp_self_stop();
console_verbose();
bust_spinlocks(1);
_
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] panic: Don't print redundant backtraces on oops
2011-12-17 0:52 ` Andrew Morton
@ 2011-12-19 14:09 ` Michael Holzheu
2011-12-19 18:34 ` Andi Kleen
0 siblings, 1 reply; 4+ messages in thread
From: Michael Holzheu @ 2011-12-19 14:09 UTC (permalink / raw)
To: Andrew Morton; +Cc: Andi Kleen, linux-kernel, Andi Kleen
Hello Andrew,
On Fri, 2011-12-16 at 16:52 -0800, Andrew Morton wrote:
> On Wed, 7 Dec 2011 16:36:43 -0800
> Andi Kleen <andi@firstfloor.org> wrote:
[snip]
> > --- a/kernel/panic.c
> > +++ b/kernel/panic.c
> > @@ -78,7 +78,8 @@ NORET_TYPE void panic(const char * fmt, ...)
> > va_end(args);
> > printk(KERN_EMERG "Kernel panic - not syncing: %s\n",buf);
> > #ifdef CONFIG_DEBUG_BUGVERBOSE
> > - dump_stack();
> > + if (!oops_in_progress)
> > + dump_stack();
> > #endif
>
> This is kinda related to Michael's
> kdump-fix-crash_kexec-smp_send_stop-race-in-panic.patch, below.
>
> afacit Michael's patch will prevent panic-within-panic, and it does
> this by accident becasue we never thought about it. But it won't fix
> panic-within-other-oops.
>
> Is there some clever way in which we can satisfy both requirements in
> one hit?
I think the two problems are not related. My problem was that only one
CPU should execute panic. Andi's problem is that one (or more oops)
messages are scrolled away by a subsequent panic.
But I am not sure if Andi's patch solves all his problems. What e.g.
about panic_on_oom? Don't we have the same problem here?
Michael
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] panic: Don't print redundant backtraces on oops
2011-12-19 14:09 ` Michael Holzheu
@ 2011-12-19 18:34 ` Andi Kleen
0 siblings, 0 replies; 4+ messages in thread
From: Andi Kleen @ 2011-12-19 18:34 UTC (permalink / raw)
To: holzheu; +Cc: Andrew Morton, Andi Kleen, linux-kernel
it?
> I think the two problems are not related. My problem was that only one
> CPU should execute panic. Andi's problem is that one (or more oops)
> messages are scrolled away by a subsequent panic.
Yes it's just for making panic less chatty.
> But I am not sure if Andi's patch solves all his problems. What e.g.
> about panic_on_oom? Don't we have the same problem here?
Yes, it only solves it for this specific -- but common -- case. Or at
least it was a case
that annoyed me and prompted me to write the patch :)
I had a patch some time ago for a xpanic() where the caller could pass
in additional
flags, including one to disable the backtrace. But that was a much
larger patch,
this was a simpler alternative.
-Andi
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-12-19 18:34 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-08 0:36 [PATCH] panic: Don't print redundant backtraces on oops Andi Kleen
2011-12-17 0:52 ` Andrew Morton
2011-12-19 14:09 ` Michael Holzheu
2011-12-19 18:34 ` Andi Kleen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).