1. 17 Mar, 2009 2 commits
    • Suresh Siddha's avatar
      x86, dmar: move page fault handling code to dmar.c · 0ac2491f
      Suresh Siddha authored
      Impact: code movement
      
      Move page fault handling code to dmar.c
      This will be shared both by DMA-remapping and Intr-remapping code.
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      0ac2491f
    • Suresh Siddha's avatar
      x86, x2apic: fix lock ordering during IRQ migration · 4c5502b1
      Suresh Siddha authored
      Impact: fix potential deadlock on x2apic
      
      fix "hard-safe -> hard-unsafe lock order detected" with irq_2_ir_lock
      
      On x2apic enabled system:
         [ INFO: hard-safe -> hard-unsafe lock order detected ]
         2.6.27-03151-g4480f15b #1
         ------------------------------------------------------
         swapper/1 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
          (irq_2_ir_lock){--..}, at: [<ffffffff8038ebc0>] get_irte+0x2f/0x95
      
         and this task is already holding:
          (&irq_desc_lock_class){+...}, at: [<ffffffff802649ed>] setup_irq+0x67/0x281
         which would create a new lock dependency:
          (&irq_desc_lock_class){+...} -> (irq_2_ir_lock){--..}
      
         but this new dependency connects a hard-irq-safe lock:
          (&irq_desc_lock_class){+...}
         ... which became hard-irq-safe at:
           [<ffffffffffffffff>] 0xffffffffffffffff
      
         to a hard-irq-unsafe lock:
          (irq_2_ir_lock){--..}
         ... which became hard-irq-unsafe at:
         ...  [<ffffffff802547b5>] __lock_acquire+0x571/0x706
           [<ffffffff8025499f>] lock_acquire+0x55/0x71
           [<ffffffff8062f2c4>] _spin_lock+0x2c/0x38
           [<ffffffff8038ee50>] alloc_irte+0x8a/0x14b
           [<ffffffff8021f733>] setup_IO_APIC_irq+0x119/0x30e
           [<ffffffff8090860e>] setup_IO_APIC+0x146/0x6e5
           [<ffffffff809058fc>] native_smp_prepare_cpus+0x24e/0x2e9
           [<ffffffff808f982c>] kernel_init+0x5a/0x176
           [<ffffffff8020c289>] child_rip+0xa/0x11
           [<ffffffffffffffff>] 0xffffffffffffffff
      
      Fix this theoretical lock order issue by using spin_lock_irqsave() instead of
      spin_lock()
      Signed-off-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      4c5502b1
  2. 14 Mar, 2009 6 commits
  3. 13 Mar, 2009 18 commits
  4. 12 Mar, 2009 14 commits