[PATCH] Linux 2.6.x VM86 interrupt emulation fixes - the second round

From: Pavel Pisa
Date: Tue Apr 26 2005 - 03:49:26 EST

Patch solves VM86 interrupt emulation deadlock on SMP systems.
The VM86 interrupt emulation has been heavily tested and works
well on UP systems after last update, but it seems to deadlock
when we have used it on SMP/HT boxes now.
It seems, that disable_irq() cannot be called from interrupts,
because it waits until disabled interrupt handler finishes
This blocks one CPU after another. Solved by use disable_irq_nosync.
There is the second problem. If IRQ source is fast, it is possible,
that interrupt is sometimes processed and re-enabled by the second
CPU, before it is disabled by the first one, but negative IRQ disable
depths are not allowed. The spinlocking and disabling IRQs over
call to disable_irq_nosync/enable_irq is the only solution found
reliable till now.

Signed-off-by: Michal Sojka <sojkam1@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Pavel Pisa <pisa@xxxxxxxxxxxxxxxx>

Index: linux-
--- linux-
+++ linux-
@@ -732,12 +732,12 @@ static irqreturn_t irq_handler(int intno
irqbits |= irq_bit;
if (vm86_irqs[intno].sig)
send_sig(vm86_irqs[intno].sig, vm86_irqs[intno].tsk, 1);
- spin_unlock_irqrestore(&irqbits_lock, flags);
* IRQ will be re-enabled when user asks for the irq (whether
* polling or as a result of the signal)
- disable_irq(intno);
+ disable_irq_nosync(intno);
+ spin_unlock_irqrestore(&irqbits_lock, flags);

@@ -769,17 +769,20 @@ static inline int get_and_reset_irq(int
int bit;
unsigned long flags;
+ int ret = 0;

if (invalid_vm86_irq(irqnumber)) return 0;
if (vm86_irqs[irqnumber].tsk != current) return 0;
spin_lock_irqsave(&irqbits_lock, flags);
bit = irqbits & (1 << irqnumber);
irqbits &= ~bit;
+ if (bit) {
+ enable_irq(irqnumber);
+ ret = 1;
+ }
spin_unlock_irqrestore(&irqbits_lock, flags);
- if (!bit)
- return 0;
- enable_irq(irqnumber);
- return 1;
+ return ret;

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/