From: Pavel Emelianov <xemul@openvz.org>
To: Andrew Morton <akpm@osdl.org>,
mingo@redhat.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Kirill Korotaev <dev@openvz.org>
Subject: [RFC] [PATCH] Fix misrouted interrupts deadlocks
Date: Fri, 10 Nov 2006 16:55:48 +0300 [thread overview]
Message-ID: <455484E4.1020100@openvz.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]
While testing kernel on machine with "irqpoll" option
I've caught such a lockup:
__do_IRQ()
spin_lock(&desc->lock);
desc->chip->ack(); /* IRQ is ACKed */
note_interrupt()
misrouted_irq()
handle_IRQ_event()
if (...)
local_irq_enable_in_hardirq();
/* interrupts are enabled from now */
...
__do_IRQ() /* same IRQ we've started from */
spin_lock(&desc->lock); /* LOCKUP */
Looking at misrouted_irq() code I've found that a potential
deadlock like this can also take place:
1CPU:
__do_IRQ()
spin_lock(&desc->lock); /* irq = A */
misrouted_irq()
for (i = 1; i < NR_IRQS; i++) {
spin_lock(&desc->lock); /* irq = B */
if (desc->status & IRQ_INPROGRESS) {
2CPU:
__do_IRQ()
spin_lock(&desc->lock); /* irq = B */
misrouted_irq()
for (i = 1; i < NR_IRQS; i++) {
spin_lock(&desc->lock); /* irq = A */
if (desc->status & IRQ_INPROGRESS) {
As the second lock on booth CPUs is taken before checking that
this irq is being handled in another processor this may cause
a deadlock. This issue is only theoretical.
I propose the attached patch to fix booth problems: when trying
to handle misrouted IRQ active desc->lock may be unlocked.
Please comment.
[-- Attachment #2: diff-misrouted-irq-lockup --]
[-- Type: text/plain, Size: 536 bytes --]
--- ./kernel/irq/spurious.c.irqlockup 2006-11-09 11:19:10.000000000 +0300
+++ ./kernel/irq/spurious.c 2006-11-10 16:53:38.000000000 +0300
@@ -147,7 +147,11 @@ void note_interrupt(unsigned int irq, st
if (unlikely(irqfixup)) {
/* Don't punish working computers */
if ((irqfixup == 2 && irq == 0) || action_ret == IRQ_NONE) {
- int ok = misrouted_irq(irq);
+ int ok;
+
+ spin_unlock(&desc->lock);
+ ok = misrouted_irq(irq);
+ spin_lock(&desc->lock);
if (action_ret == IRQ_NONE)
desc->irqs_unhandled -= ok;
}
next reply other threads:[~2006-11-10 14:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-10 13:55 Pavel Emelianov [this message]
2006-11-10 14:12 ` [RFC] [PATCH] Fix misrouted interrupts deadlocks Ingo Molnar
2006-11-10 14:31 ` Pavel Emelianov
2006-11-20 19:23 ` Vivek Goyal
2006-11-20 19:56 ` Vivek Goyal
2006-11-20 20:52 ` Vivek Goyal
2006-11-21 8:01 ` Pavel Emelianov
2006-11-21 8:10 ` Pavel Emelianov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=455484E4.1020100@openvz.org \
--to=xemul@openvz.org \
--cc=akpm@osdl.org \
--cc=dev@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox