Re: [patch] irqlock patch -G3. [was Re: odd memory corruption in 2.5.27?]

[Robert Love <rml@tech9.net>]

On Tue, 2002-07-23 at 16:28, Ingo Molnar wrote:

> this is most definitely not the correct fix ...
> 
> i'm quite convinced that the fix is to avoid illegal preemption, not to
> work it around.

I am not sure I am fully convinced one way or the other, but treating
every bit of code as we find it scares me.  The fact is, if a
spin_unlock() can magically reenable interrupts that is a bug.

I don't like relying on chance and the possibility your debug tool found
the problem... but at the same time, Ingo's solution is a lot cleaner.

Linus, Ingo, comments?

Attached is the patch George mentioned, against 2.5.27.

	Robert Love

diff -urN linux-2.5.27/include/asm-i386/system.h linux/include/asm-i386/system.h
--- linux-2.5.27/include/asm-i386/system.h	Sat Jul 20 12:11:05 2002
+++ linux/include/asm-i386/system.h	Tue Jul 23 18:03:47 2002
@@ -270,6 +270,13 @@
 /* Compiling for a 386 proper.	Is it worth implementing via cli/sti?  */
 #endif
 
+#define MASK_IF			0x200
+#define interrupts_enabled()	({ \
+		int flg; \
+		__save_flags(flg); \
+		flg & MASK_IF; \
+})
+
 /*
  * Force strict CPU ordering.
  * And yes, this is required on UP too when we're talking
diff -urN linux-2.5.27/kernel/sched.c linux/kernel/sched.c
--- linux-2.5.27/kernel/sched.c	Sat Jul 20 12:11:11 2002
+++ linux/kernel/sched.c	Tue Jul 23 18:02:13 2002
@@ -899,7 +899,7 @@
 {
 	struct thread_info *ti = current_thread_info();
 
-	if (unlikely(ti->preempt_count))
+	if (unlikely(ti->preempt_count || !interrupts_enabled()))
 		return;
 
 need_resched: