Skip to contentSkip to conversation

i386: don't blindly enable interrupts in die()

PATCH In review Jan Beulich 2 participants 3 messages Nov 8, 2005 – Nov 9, 2005

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 i386: don't blindly enable interrupts in die()

Rather than blindly re-enabling interrupts in die(), save their state upon entry and then restore that state.

From: Jan Beulich <[email protected]>

(actual patch attached)

Rather than blindly re-enabling interrupts in die(), save their state upon entry and then restore that state.

From: Jan Beulich <[email protected]>

arch/i386/kernel/traps.c +5 -2
@@ -306,14 +306,17 @@ void die(const char * str, struct pt_reg
 		.lock_owner_depth =	0
 	};
 	static int die_counter;
+	unsigned long flags;
 
 	if (die.lock_owner != raw_smp_processor_id()) {
 		console_verbose();
-		spin_lock_irq(&die.lock);
+		spin_lock_irqsave(&die.lock, flags);
 		die.lock_owner = smp_processor_id();
 		die.lock_owner_depth = 0;
 		bust_spinlocks(1);
 	}
+	else
+		local_save_flags(flags);
 
 	if (++die.lock_owner_depth < 3) {
 		int nl = 0;
@@ -340,7 +343,7 @@ void die(const char * str, struct pt_reg
 
 	bust_spinlocks(0);
 	die.lock_owner = -1;
-	spin_unlock_irq(&die.lock);
+	spin_unlock_irqrestore(&die.lock, flags);
 
 	if (kexec_should_crash(current))
 		crash_kexec(regs);
#1 lore raw
Quoted 3 lines · Jan Beulich

Rather than blindly re-enabling interrupts in die(), save their state upon entry and then restore that state.

What is the reason for this change?

#2 lore raw
Quoted 4 lines
Quoted 1 line
Quoted 1 line

Andrew Morton <[email protected]> 08.11.05 23:57:21 >>>

Quoted 2 lines · Jan Beulich

Rather than blindly re-enabling interrupts in die(), save their

state

Quoted 3 lines
Quoted 1 line

upon entry and then restore that state.

What is the reason for this change?

If the kernel is in really bad condition and faults with interrupts disabled, re-enabling them in die() may cause even more trouble, implying more chances of data corruption.