1. 16 10月, 2015 1 次提交
    • V
      x86/ioapic: Disable interrupts when re-routing legacy IRQs · c0ff971e
      Vitaly Kuznetsov 提交于
      A sporadic hang with consequent crash is observed when booting Hyper-V Gen1
      guests:
      
       Call Trace:
        <IRQ>
        [<ffffffff810ab68d>] ? trace_hardirqs_off+0xd/0x10
        [<ffffffff8107b616>] queue_work_on+0x46/0x90
        [<ffffffff81365696>] ? add_interrupt_randomness+0x176/0x1d0
        ...
        <EOI>
        [<ffffffff81471ddb>] ? _raw_spin_unlock_irqrestore+0x3b/0x60
        [<ffffffff810c295e>] __irq_put_desc_unlock+0x1e/0x40
        [<ffffffff810c5c35>] irq_modify_status+0xb5/0xd0
        [<ffffffff8104adbb>] mp_register_handler+0x4b/0x70
        [<ffffffff8104c55a>] mp_irqdomain_alloc+0x1ea/0x2a0
        [<ffffffff810c7f10>] irq_domain_alloc_irqs_recursive+0x40/0xa0
        [<ffffffff810c860c>] __irq_domain_alloc_irqs+0x13c/0x2b0
        [<ffffffff8104b070>] alloc_isa_irq_from_domain.isra.1+0xc0/0xe0
        [<ffffffff8104bfa5>] mp_map_pin_to_irq+0x165/0x2d0
        [<ffffffff8104c157>] pin_2_irq+0x47/0x80
        [<ffffffff81744253>] setup_IO_APIC+0xfe/0x802
        ...
        [<ffffffff814631c0>] ? rest_init+0x140/0x140
      
      The issue is easily reproducible with a simple instrumentation: if
      mdelay(10) is put between mp_setup_entry() and mp_register_handler() calls
      in mp_irqdomain_alloc() Hyper-V guest always fails to boot when re-routing
      IRQ0. The issue seems to be caused by the fact that we don't disable
      interrupts while doing IOPIC programming for legacy IRQs and IRQ0 actually
      happens. 
      
      Protect the setup sequence against concurrent interrupts.
      
      [ tglx: Make the protection unconditional and not only for legacy
        	interrupts ]
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Link: http://lkml.kernel.org/r/1444930943-19336-1-git-send-email-vkuznets@redhat.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      c0ff971e
  2. 15 9月, 2015 1 次提交
    • T
      x86/ioapic: Force affinity setting in setup_ioapic_dest() · 4857c91f
      Thomas Gleixner 提交于
      The recent ioapic cleanups changed the affinity setting in
      setup_ioapic_dest() from a direct write to the hardware to the delayed
      affinity setup via irq_set_affinity().
      
      That results in a warning from chained_irq_exit():
      WARNING: CPU: 0 PID: 5 at kernel/irq/migration.c:32 irq_move_masked_irq
      [<ffffffff810a0a88>] irq_move_masked_irq+0xb8/0xc0
      [<ffffffff8103c161>] ioapic_ack_level+0x111/0x130
      [<ffffffff812bbfe8>] intel_gpio_irq_handler+0x148/0x1c0
      
      The reason is that irq_set_affinity() does not write directly to the
      hardware. It marks the affinity setting as pending and executes it
      from the next interrupt. The chained handler infrastructure does not
      take the irq descriptor lock for performance reasons because such a
      chained interrupt is not visible to any interfaces. So the delayed
      affinity setting triggers the warning in irq_move_masked_irq().
      
      Restore the old behaviour by calling the set_affinity function of the
      ioapic chip in setup_ioapic_dest(). This is safe as none of the
      interrupts can be on the fly at this point.
      
      Fixes: aa5cb97f 'x86/irq: Remove x86_io_apic_ops.set_affinity and related interfaces'
      Reported-and-tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: jarkko.nikula@linux.intel.com
      4857c91f
  3. 31 7月, 2015 1 次提交
  4. 14 7月, 2015 1 次提交
  5. 10 5月, 2015 1 次提交
  6. 24 4月, 2015 24 次提交
  7. 22 1月, 2015 2 次提交
  8. 16 12月, 2014 9 次提交