[PATCH 1/1] x86_64 irq: Scream but don't die if we receive an unexpected irq

[ebiederm@xmission.com (Eric W. Biederman)]

Due to code bugs or misbehaving hardware it is possible that we
can receive an interrupt that we have not mapped into a linux irq.
Calling BUG when that happens is very rude, and if the problem
is mild enough prevents anything else from getting done.

So instead of calling BUG just scream loudly about the problem
and continue running.  We don't have enough knowledge to know
which interrupt triggered this behavior so we don't acknowledge it.
This will likely prevent a recurrence of the problem by jamming
up the works with an unacknowledged interrupt.

If the interrupt was something important it is quite possible
that nothing productive will happen past this point.  But
it is now at least possible to keep working if the kernel
can survive without the interrupt we dropped on the floor.

Solutions like irqpoll should generally make dropped irqs non-fatal.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 arch/x86_64/kernel/irq.c |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86_64/kernel/irq.c b/arch/x86_64/kernel/irq.c
index b8a407f..dff68eb 100644
--- a/arch/x86_64/kernel/irq.c
+++ b/arch/x86_64/kernel/irq.c
@@ -114,16 +114,16 @@ asmlinkage unsigned int do_IRQ(struct pt
 	irq_enter();
 	irq = __get_cpu_var(vector_irq)[vector];
 
-	if (unlikely(irq >= NR_IRQS)) {
-		printk(KERN_EMERG "%s: cannot handle IRQ %d\n",
-					__FUNCTION__, irq);
-		BUG();
-	}
-
 #ifdef CONFIG_DEBUG_STACKOVERFLOW
 	stack_overflow_check(regs);
 #endif
-	generic_handle_irq(irq);
+
+	if (likely(irq < NR_IRQS))
+		generic_handle_irq(irq);
+	else
+		printk(KERN_EMERG "%s: %d.%d No irq handler for vector\n",
+			__func__, smp_processor_id(), vector);
+
 	irq_exit();
 
 	set_irq_regs(old_regs);
-- 
1.4.2.rc3.g7e18e-dirty