__global_sti() appears to have a similar bug as __global_cli(), but it's a
bit more complex to trigger:
if a syscall-level, irqs-enabled process does a sti() but it does not hold
the IRQ spinlock, and the process gets preempted after the 'cpu'
assignment and gets run on another CPU, and the original CPU runs another
process that does a cli() which holds the global IRQ lock, then the rest
of __global_sti() will incorrectly release the IRQ lock - possibly causing
an oops in the other process.
this too is a few instructions race but looks quite serious at first
sight.
(the fix is to disable preemption around the critical section.)
Ingo
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.510 -> 1.511
# arch/i386/kernel/irq.c 1.10 -> 1.11
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/06/17 mingo@elte.hu 1.511
# - sti() preemption bugfix.
# --------------------------------------------
#
diff -Nru a/arch/i386/kernel/irq.c b/arch/i386/kernel/irq.c
--- a/arch/i386/kernel/irq.c Mon Jun 17 17:00:30 2002
+++ b/arch/i386/kernel/irq.c Mon Jun 17 17:00:30 2002
@@ -368,9 +368,11 @@
{
int cpu = smp_processor_id();
+ preempt_disable();
if (!local_irq_count(cpu))
release_irqlock(cpu);
__sti();
+ preempt_enable();
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 23 2002 - 22:00:13 EST