1. 26 5月, 2017 1 次提交
  2. 09 2月, 2017 1 次提交
    • L
      Revert "x86/ioapic: Restore IO-APIC irq_chip retrigger callback" · d966564f
      Linus Torvalds 提交于
      This reverts commit 020eb3da.
      
      Gabriel C reports that it causes his machine to not boot, and we haven't
      tracked down the reason for it yet.  Since the bug it fixes has been
      around for a longish time, we're better off reverting the fix for now.
      
      Gabriel says:
       "It hangs early and freezes with a lot RCU warnings.
      
        I bisected it down to :
      
        > Ruslan Ruslichenko (1):
        >       x86/ioapic: Restore IO-APIC irq_chip retrigger callback
      
        Reverting this one fixes the problem for me..
      
        The box is a PRIMERGY TX200 S5 , 2 socket , 2 x E5520 CPU(s) installed"
      
      and Ruslan and Thomas are currently stumped.
      Reported-and-bisected-by: NGabriel C <nix.or.die@gmail.com>
      Cc: Ruslan Ruslichenko <rruslich@cisco.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: stable@kernel.org   # for the backport of the original commit
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d966564f
  3. 01 2月, 2017 1 次提交
  4. 20 1月, 2017 1 次提交
  5. 18 1月, 2017 2 次提交
  6. 10 12月, 2016 1 次提交
  7. 20 9月, 2016 1 次提交
  8. 14 7月, 2016 1 次提交
    • P
      x86/kernel: Audit and remove any unnecessary uses of module.h · 186f4360
      Paul Gortmaker 提交于
      Historically a lot of these existed because we did not have
      a distinction between what was modular code and what was providing
      support to modules via EXPORT_SYMBOL and friends.  That changed
      when we forked out support for the latter into the export.h file.
      
      This means we should be able to reduce the usage of module.h
      in code that is obj-y Makefile or bool Kconfig.  The advantage
      in doing so is that module.h itself sources about 15 other headers;
      adding significantly to what we feed cpp, and it can obscure what
      headers we are effectively using.
      
      Since module.h was the source for init.h (for __init) and for
      export.h (for EXPORT_SYMBOL) we consider each obj-y/bool instance
      for the presence of either and replace as needed.  Build testing
      revealed some implicit header usage that was fixed up accordingly.
      
      Note that some bool/obj-y instances remain since module.h is
      the header for some exception table entry stuff, and for things
      like __init_or_module (code that is tossed when MODULES=n).
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20160714001901.31603-4-paul.gortmaker@windriver.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      186f4360
  9. 04 7月, 2016 1 次提交
  10. 10 6月, 2016 2 次提交
  11. 13 4月, 2016 1 次提交
  12. 15 1月, 2016 1 次提交
  13. 27 10月, 2015 1 次提交
    • W
      x86/ioapic: Prevent NULL pointer dereference in setup_ioapic_dest() · ababae44
      Werner Pawlitschko 提交于
      Commit 4857c91f changed the way how irq affinity is setup in
      setup_ioapic_dest() from using the core helper function to
      unconditionally calling the irq_set_affinity() callback of the
      underlying irq chip.
      
      That results in a NULL pointer dereference for the rare case where the
      underlying irq chip is lapic_chip which has no irq_set_affinity()
      callback. lapic_chip is occasionally used for the timer interrupt (irq
      0).
      
      The fix is simple: Check the availability of the callback instead of
      calling it unconditionally.
      
      Fixes: 4857c91f "x86/ioapic: Force affinity setting in setup_ioapic_dest()"
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      ababae44
  14. 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
  15. 12 10月, 2015 1 次提交
  16. 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
  17. 31 7月, 2015 1 次提交
  18. 14 7月, 2015 1 次提交
  19. 10 5月, 2015 1 次提交
  20. 24 4月, 2015 19 次提交