• Ingo Molnar's avatar
    [PATCH] genirq core: fix handle_level_irq() · 86998aa6
    Ingo Molnar authored
    while porting the -rt tree to 2.6.18-rc7 i noticed the following
    screaming-IRQ scenario on an SMP system:
    
     2274  0Dn.:1 0.001ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
     2274  0Dn.:1 0.010ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
     2274  0Dn.:1 0.020ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
     2274  0Dn.:1 0.029ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
     2274  0Dn.:1 0.039ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
     2274  0Dn.:1 0.048ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
     2274  0Dn.:1 0.058ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
     2274  0Dn.:1 0.068ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
     2274  0Dn.:1 0.077ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
     2274  0Dn.:1 0.087ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
     2274  0Dn.:1 0.097ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
    
    as it turns out, the bug is caused by handle_level_irq(), which if it
    races with another CPU already handling this IRQ, it _unmasks_ the IRQ
    line on the way out. This is not how 2.6.17 works, and we introduced
    this bug in one of the early genirq cleanups right before it went into
    -mm. (the bug was not in the genirq patchset for a long time, and we
    didnt notice the bug due to the lack of -rt rebase to the new genirq
    code. -rt, and hardirq-preemption in particular opens up such races much
    wider than anything else.)
    Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Acked-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    86998aa6
chip.c 12.9 KB