1. 19 2月, 2011 3 次提交
    • T
      genirq: Consolidate IRQ_DISABLED · 3aae994f
      Thomas Gleixner 提交于
      Handle IRQ_DISABLED consistent.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      3aae994f
    • T
      genirq: Consolidate disable/enable · 87923470
      Thomas Gleixner 提交于
      Create irq_disable/enable and use them to keep the flags consistent.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      87923470
    • T
      genirq: Prevent access beyond allocated_irqs bitmap · c1ee6264
      Thomas Gleixner 提交于
      Lars-Peter Clausen pointed out:
      
         I stumbled upon this while looking through the existing archs using
         SPARSE_IRQ.  Even with SPARSE_IRQ the NR_IRQS is still the upper
         limit for the number of IRQs.
      
         Both PXA and MMP set NR_IRQS to IRQ_BOARD_START, with
         IRQ_BOARD_START being the number of IRQs used by the core.
      
         In various machine files the nr_irqs field of the ARM machine
         defintion struct is then set to "IRQ_BOARD_START + NR_BOARD_IRQS".
      
         As a result "nr_irqs" will greater then NR_IRQS which then again
         causes the "allocated_irqs" bitmap in the core irq code to be
         accessed beyond its size overwriting unrelated data.
      
      The core code really misses a sanity check there.
      
      This went unnoticed so far as by chance the compiler/linker places
      data behind that bitmap which gets initialized later on those affected
      platforms.
      
      So the obvious fix would be to add a sanity check in early_irq_init()
      and break all affected platforms. Though that check wants to be
      backported to stable as well, which will require to fix all known
      problematic platforms and probably some more yet not known ones as
      well. Lots of churn.
      
      A way simpler solution is to allocate a slightly larger bitmap and
      avoid the whole churn w/o breaking anything. Add a few warnings when
      an arch returns utter crap.
      Reported-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: stable@kernel.org # .37
      Cc: Haojian Zhuang <haojian.zhuang@marvell.com>
      Cc: Eric Miao <eric.y.miao@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      c1ee6264
  2. 04 10月, 2010 3 次提交
  3. 09 8月, 2009 1 次提交
  4. 16 10月, 2008 2 次提交
  5. 13 8月, 2007 1 次提交
  6. 09 8月, 2007 1 次提交
  7. 02 8月, 2007 1 次提交
    • T
      genirq: temporary fix for level-triggered IRQ resend · 0fc4969b
      Thomas Gleixner 提交于
      Marcin Slusarz reported a ne2k-pci "hung network interface" regression.
      
      delayed disable relies on the ability to re-trigger the interrupt in the
      case that a real interrupt happens after the software disable was set.
      In this case we actually disable the interrupt on the hardware level
      _after_ it occurred.
      
      On enable_irq, we need to re-trigger the interrupt. On i386 this relies
      on a hardware resend mechanism (send_IPI_self()).
      
      Actually we only need the resend for edge type interrupts. Level type
      interrupts come back once enable_irq() re-enables the interrupt line.
      
      I assume that the interrupt in question is level triggered because it is
      shared and above the legacy irqs 0-15:
      
      	17:         12   IO-APIC-fasteoi   eth1, eth0
      
      Looking into the IO_APIC code, the resend via send_IPI_self() happens
      unconditionally. So the resend is done for level and edge interrupts.
      This makes the problem more mysterious.
      
      The code in question lib8390.c does
      
      	disable_irq();
      	fiddle_with_the_network_card_hardware()
      	enable_irq();
      
      The fiddle_with_the_network_card_hardware() might cause interrupts,
      which are cleared in the same code path again,
      
      Marcin found that when he disables the irq line on the hardware level
      (removing the delayed disable) the card is kept alive.
      
      So the difference is that we can get a resend on enable_irq, when an
      interrupt happens during the time, where we are in the disabled region.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0fc4969b
  8. 07 10月, 2006 1 次提交
  9. 17 9月, 2006 1 次提交
  10. 30 6月, 2006 2 次提交