panic_on_oops: remove ssleep()

PATCH In review Horms 4 participants 6 messages Jul 17, 2006 – Jul 20, 2006

Subsystems (3)

Arm (32-bit) PowerPC Tensilica Xtensa port (xtensa)

lore

Share & tools

lore

Horms

author

2006-07-17 16:17 UTC #0 lore raw

PATCH 1/1 panic_on_oops: remove ssleep()

This patch is part of an effort to unify the panic_on_oops behaviour across all architectures that implement it.

It was pointed out to me by Andi Kleen that if an oops has occured in interrupt context, then calling sleep() in the oops path will only cause a panic, and that it would be really better for it not to be in the path at all.

This patch removes the ssleep() call and reworks the console message accordinly. I have a slght concern that the resulting console message is too long, feedback welcome.

For powerpc it also unifies the 32bit and 64bit behaviour.

Fror x86_64, this patch only updates the console message, as ssleep() is already not present.

Signed-off-by Horms <[email protected]>

 arch/arm/kernel/traps.c     |    7 ++-----
 arch/i386/kernel/traps.c    |    8 +++-----
 arch/ia64/kernel/traps.c    |    7 ++-----
 arch/powerpc/kernel/traps.c |   10 +++-------
 arch/x86_64/kernel/traps.c  |    2 +-
 arch/xtensa/kernel/traps.c  |    8 +++-----
 6 files changed, 14 insertions(+), 28 deletions(-)

arch/arm/kernel/traps.c +2 -5

@@ -232,11 +232,8 @@ NORET_TYPE void die(const char *str, str
 	bust_spinlocks(0);
 	spin_unlock_irq(&die_lock);
 
-	if (panic_on_oops) {
-		printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
-		ssleep(5);
-		panic("Fatal exception");
-	}
+	if (panic_on_oops)
+		panic("Fatal exception: panic_on_oops");
 
 	do_exit(SIGSEGV);
 }

arch/i386/kernel/traps.c +3 -5

@@ -442,11 +442,9 @@ #endif
 	if (in_interrupt())
 		panic("Fatal exception in interrupt");
 
-	if (panic_on_oops) {
-		printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
-		ssleep(5);
-		panic("Fatal exception");
-	}
+	if (panic_on_oops)
+		panic("Fatal exception: panic_on_oops");
+
 	oops_exit();
 	do_exit(SIGSEGV);
 }

arch/ia64/kernel/traps.c +2 -5

@@ -117,11 +117,8 @@ die (const char *str, struct pt_regs *re
 	die.lock_owner = -1;
 	spin_unlock_irq(&die.lock);
 
-	if (panic_on_oops) {
-		printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
-		ssleep(5);
-		panic("Fatal exception");
-	}
+	if (panic_on_oops)
+		panic("Fatal exception: panic_on_oops");
 
   	do_exit(SIGSEGV);
 }

arch/powerpc/kernel/traps.c +3 -7

@@ -150,13 +150,9 @@ #endif
 	if (in_interrupt())
 		panic("Fatal exception in interrupt");
 
-	if (panic_on_oops) {
-#ifdef CONFIG_PPC64
-		printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
-		ssleep(5);
-#endif
-		panic("Fatal exception");
-	}
+	if (panic_on_oops)
+		panic("Fatal exception: panic_on_oops");
+
 	do_exit(err);
 
 	return 0;

arch/x86_64/kernel/traps.c +1 -1

@@ -521,7 +521,7 @@ void __kprobes oops_end(unsigned long fl
 		/* Nest count reaches zero, release the lock. */
 		spin_unlock_irqrestore(&die_lock, flags);
 	if (panic_on_oops)
-		panic("Oops");
+		panic("Fatal exception: panic_on_oops");
 }
 
 void __kprobes __die(const char * str, struct pt_regs * regs, long err)

arch/xtensa/kernel/traps.c +3 -5

@@ -487,11 +487,9 @@ #endif
 	if (in_interrupt())
 		panic("Fatal exception in interrupt");
 
-	if (panic_on_oops) {
-		printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
-		ssleep(5);
-		panic("Fatal exception");
-	}
+	if (panic_on_oops)
+		panic("Fatal exception: panic_on_oops");
+
 	do_exit(err);
 }

Andi Kleen

2006-07-17 22:27 UTC #1 lore raw

Quoted 11 lines · Horms

This patch is part of an effort to unify the panic_on_oops behaviour across all architectures that implement it.
It was pointed out to me by Andi Kleen that if an oops has occured in interrupt context, then calling sleep() in the oops path will only cause a panic, and that it would be really better for it not to be in the path at all.
This patch removes the ssleep() call and reworks the console message accordinly. I have a slght concern that the resulting console message is too long, feedback welcome.

Keeping the delay might be actually useful so that you can see the panic before system reboots when reboot on panic is enabled. I would just use a loop of mdelays(1) with touch_nmi_watchdog/touch_softirq_watchdog()s inbetween.

-Andi

Horms

author

2006-07-17 23:10 UTC #2 lore raw

Quoted 9 lines · Andi Kleen

Quoted 8 lines · Horms
This patch is part of an effort to unify the panic_on_oops behaviour across all architectures that implement it.
It was pointed out to me by Andi Kleen that if an oops has occured in interrupt context, then calling sleep() in the oops path will only cause a panic, and that it would be really better for it not to be in the path at all.

Quoted 8 lines

Quoted 3 lines
This patch removes the ssleep() call and reworks the console message accordinly. I have a slght concern that the resulting console message is too long, feedback welcome.
Keeping the delay might be actually useful so that you can see the panic before system reboots when reboot on panic is enabled. I would just use a loop of mdelays(1) with touch_nmi_watchdog/touch_softirq_watchdog()s inbetween.

Ok, I will look into making that happen. I agree that the pause is quite useful.

Signature · 3 lines

Horms                                           
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

Andrew Morton

2006-07-18 00:23 UTC #3 lore raw

Quoted 10 lines · On Mon, 17 Jul 2006 19:10:59 -0400 Horms <[email protected]> wrote:

Quoted 6 lines · Andi Kleen
On Monday 17 July 2006 18:17, Horms wrote:
...
Keeping the delay might be actually useful so that you can see the panic before system reboots when reboot on panic is enabled. I would just use a loop of mdelays(1) with touch_nmi_watchdog/touch_softirq_watchdog()s inbetween.
Ok, I will look into making that happen. I agree that the pause is quite useful.

It's kind-of already implemented, via pause_on_oops. Perhaps doing something like

	if (panic_on_oops)
		pause_on_oops = max(pause_on_oops, 5*HZ);

would be sufficient.

Horms

author

2006-07-18 19:13 UTC #4 lore raw

Quoted 14 lines · Andrew Morton

Quoted 10 lines · On Mon, 17 Jul 2006 19:10:59 -0400 Horms <[email protected]> wrote:
Quoted 6 lines · Andi Kleen
On Monday 17 July 2006 18:17, Horms wrote:
...
Keeping the delay might be actually useful so that you can see the panic before system reboots when reboot on panic is enabled. I would just use a loop of mdelays(1) with touch_nmi_watchdog/touch_softirq_watchdog()s inbetween.
Ok, I will look into making that happen. I agree that the pause is quite useful.

Quoted 7 lines

It's kind-of already implemented, via pause_on_oops. Perhaps doing something like
	if (panic_on_oops)
		pause_on_oops = max(pause_on_oops, 5*HZ);
would be sufficient.

Thanks, that may well be sufficient. And I assume that it is nicely out of the arch-dependant code in die(). I will poke around a bit more.

Signature · 3 lines

Horms                                           
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

Paul Mackerras

Acked-by on v1 1/1

2006-07-20 16:03 UTC #5 lore raw

In reply to Horms

Quoted 2 lines · Horms

This patch is part of an effort to unify the panic_on_oops behaviour across all architectures that implement it.

Acked-by Paul Mackerras <[email protected]>