1. 16 5月, 2014 5 次提交
  2. 06 5月, 2014 1 次提交
  3. 28 4月, 2014 1 次提交
    • T
      genirq: x86: Ensure that dynamic irq allocation does not conflict · 62a08ae2
      Thomas Gleixner 提交于
      On x86 the allocation of irq descriptors may allocate interrupts which
      are in the range of the GSI interrupts. That's wrong as those
      interrupts are hardwired and we don't have the irq domain translation
      like PPC. So one of these interrupts can be hooked up later to one of
      the devices which are hard wired to it and the io_apic init code for
      that particular interrupt line happily reuses that descriptor with a
      completely different configuration so hell breaks lose.
      
      Inside x86 we allocate dynamic interrupts from above nr_gsi_irqs,
      except for a few usage sites which have not yet blown up in our face
      for whatever reason. But for drivers which need an irq range, like the
      GPIO drivers, we have no limit in place and we don't want to expose
      such a detail to a driver.
      
      To cure this introduce a function which an architecture can implement
      to impose a lower bound on the dynamic interrupt allocations.
      
      Implement it for x86 and set the lower bound to nr_gsi_irqs, which is
      the end of the hardwired interrupt space, so all dynamic allocations
      happen above.
      
      That not only allows the GPIO driver to work sanely, it also protects
      the bogus callsites of create_irq_nr() in hpet, uv, irq_remapping and
      htirq code. They need to be cleaned up as well, but that's a separate
      issue.
      Reported-by: NJin Yao <yao.jin@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Krogerus Heikki <heikki.krogerus@intel.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1404241617360.28206@ionos.tec.linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      62a08ae2
  4. 16 4月, 2014 1 次提交
    • P
      x86/irq: Fix fixup_irqs() error handling · fb24da80
      Prarit Bhargava 提交于
      Several patches to fix cpu hotplug and the down'd cpu's irq
      relocations have been submitted in the past month or so.  The
      patches should resolve the problems with cpu hotplug and irq
      relocation, however, there is always a possibility that a bug
      still exists.  The big problem with debugging these irq
      reassignments is that the cpu down completes and then we get
      random stack traces from drivers for which irqs have not been
      properly assigned to a new cpu.  The stack traces are a mix of
      storage, network, and other kernel subsystem (I once saw the
      serial port stop working ...) warnings and failures.
      
      The problem with these failures is that they are difficult to
      diagnose. There is no warning in the cpu hotplug down path to
      indicate that an IRQ has failed to be assigned to a new cpu, and
      all we are left with is a stack trace from a driver, or a
      non-functional device.  If we had some information on the
      console debugging these situations would be much easier; after
      all we can map an IRQ to a device by simply using lspci or
      /proc/interrupts.
      
      The current code, fixup_irqs(), which migrates IRQs from the
      down'd cpu and is called close to the end of the cpu down path,
      calls chip->set_irq_affinity which eventually calls
      __assign_irq_vector(). Errors are not propogated back from this
      function call and this results in silent irq relocation
      failures.
      
      This patch fixes this issue by returning the error codes up the
      call stack and prints out a warning if there is a relocation
      failure.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Rui Wang <rui.y.wang@intel.com>
      Cc: Liu Ping Fan <kernelfans@gmail.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com>
      Cc: Lv Zheng <lv.zheng@intel.com>
      Cc: Seiji Aguchi <seiji.aguchi@hds.com>
      Cc: Yang Zhang <yang.z.zhang@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
      Cc: Li Fei <fei.li@intel.com>
      Cc: gong.chen@linux.intel.com
      Link: http://lkml.kernel.org/r/1396440673-18286-1-git-send-email-prarit@redhat.com
      [ Made small cleanliness tweaks. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      fb24da80
  5. 13 1月, 2014 1 次提交
  6. 12 1月, 2014 1 次提交
    • P
      x86/irq: Fix do_IRQ() interrupt warning for cpu hotplug retriggered irqs · 9345005f
      Prarit Bhargava 提交于
      During heavy CPU-hotplug operations the following spurious kernel warnings
      can trigger:
      
        do_IRQ: No ... irq handler for vector (irq -1)
      
        [ See: https://bugzilla.kernel.org/show_bug.cgi?id=64831 ]
      
      When downing a cpu it is possible that there are unhandled irqs
      left in the APIC IRR register.  The following code path shows
      how the problem can occur:
      
       1. CPU 5 is to go down.
      
       2. cpu_disable() on CPU 5 executes with interrupt flag cleared
          by local_irq_save() via stop_machine().
      
       3. IRQ 12 asserts on CPU 5, setting IRR but not ISR because
          interrupt flag is cleared (CPU unabled to handle the irq)
      
       4. IRQs are migrated off of CPU 5, and the vectors' irqs are set
          to -1. 5. stop_machine() finishes cpu_disable()
      
       6. cpu_die() for CPU 5 executes in normal context.
      
       7. CPU 5 attempts to handle IRQ 12 because the IRR is set for
          IRQ 12.  The code attempts to find the vector's IRQ and cannot
          because it has been set to -1. 8. do_IRQ() warning displays
          warning about CPU 5 IRQ 12.
      
      I added a debug printk to output which CPU & vector was
      retriggered and discovered that that we are getting bogus
      events.  I see a 100% correlation between this debug printk in
      fixup_irqs() and the do_IRQ() warning.
      
      This patchset resolves this by adding definitions for
      VECTOR_UNDEFINED(-1) and VECTOR_RETRIGGERED(-2) and modifying
      the code to use them.
      
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=64831Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Reviewed-by: NRui Wang <rui.y.wang@intel.com>
      Cc: Michel Lespinasse <walken@google.com>
      Cc: Seiji Aguchi <seiji.aguchi@hds.com>
      Cc: Yang Zhang <yang.z.zhang@Intel.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: janet.morgan@Intel.com
      Cc: tony.luck@Intel.com
      Cc: ruiv.wang@gmail.com
      Link: http://lkml.kernel.org/r/1388938252-16627-1-git-send-email-prarit@redhat.com
      [ Cleaned up the code a bit. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      9345005f
  7. 07 12月, 2013 1 次提交
    • L
      ACPI: Clean up inclusions of ACPI header files · 8b48463f
      Lv Zheng 提交于
      Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and
      <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h>
      inclusions and remove some inclusions of those files that aren't
      necessary.
      
      First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>
      should not be included directly from any files that are built for
      CONFIG_ACPI unset, because that generally leads to build warnings about
      undefined symbols in !CONFIG_ACPI builds.  For CONFIG_ACPI set,
      <linux/acpi.h> includes those files and for CONFIG_ACPI unset it
      provides stub ACPI symbols to be used in that case.
      
      Second, there are ordering dependencies between those files that always
      have to be met.  Namely, it is required that <acpi/acpi_bus.h> be included
      prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the
      latter depends on are always there.  And <acpi/acpi.h> which provides
      basic ACPICA type declarations should always be included prior to any other
      ACPI headers in CONFIG_ACPI builds.  That also is taken care of including
      <linux/acpi.h> as appropriate.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff)
      Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff)
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8b48463f
  8. 26 8月, 2013 1 次提交
  9. 20 8月, 2013 1 次提交
    • Y
      x86/ioapic/kcrash: Prevent crash_kexec() from deadlocking on ioapic_lock · 17405453
      Yoshihiro YUNOMAE 提交于
      Prevent crash_kexec() from deadlocking on ioapic_lock. When
      crash_kexec() is executed on a CPU, the CPU will take ioapic_lock
      in disable_IO_APIC(). So if the cpu gets an NMI while locking
      ioapic_lock, a deadlock will happen.
      
      In this patch, ioapic_lock is zapped/initialized before disable_IO_APIC().
      
      You can reproduce this deadlock the following way:
      
      1. Add mdelay(1000) after raw_spin_lock_irqsave() in
         native_ioapic_set_affinity()@arch/x86/kernel/apic/io_apic.c
      
         Although the deadlock can occur without this modification, it will increase
         the potential of the deadlock problem.
      
      2. Build and install the kernel
      
      3. Set up the OS which will run panic() and kexec when NMI is injected
          # echo "kernel.unknown_nmi_panic=1" >> /etc/sysctl.conf
          # vim /etc/default/grub
            add "nmi_watchdog=0 crashkernel=256M" in GRUB_CMDLINE_LINUX line
          # grub2-mkconfig
      
      4. Reboot the OS
      
      5. Run following command for each vcpu on the guest
          # while true; do echo <CPU num> > /proc/irq/<IO-APIC-edge or IO-APIC-fasteoi>/smp_affinitity; done;
         By running this command, cpus will get ioapic_lock for setting affinity.
      
      6. Inject NMI (push a dump button or execute 'virsh inject-nmi <domain>' if you
         use VM). After injecting NMI, panic() is called in an nmi-handler context.
         Then, kexec will normally run in panic(), but the operation will be stopped
         by deadlock on ioapic_lock in crash_kexec()->machine_crash_shutdown()->
         native_machine_crash_shutdown()->disable_IO_APIC()->clear_IO_APIC()->
         clear_IO_APIC_pin()->ioapic_read_entry().
      Signed-off-by: NYoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Cc: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
      Cc: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: yrl.pp-manager.tt@hitachi.com
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Seiji Aguchi <seiji.aguchi@hds.com>
      Link: http://lkml.kernel.org/r/20130820070107.28245.83806.stgit@yunodevelSigned-off-by: NIngo Molnar <mingo@kernel.org>
      17405453
  10. 28 1月, 2013 14 次提交
  11. 25 1月, 2013 1 次提交
    • A
      x86/MSI: Support multiple MSIs in presense of IRQ remapping · 51906e77
      Alexander Gordeev 提交于
      The MSI specification has several constraints in comparison with
      MSI-X, most notable of them is the inability to configure MSIs
      independently. As a result, it is impossible to dispatch
      interrupts from different queues to different CPUs. This is
      largely devalues the support of multiple MSIs in SMP systems.
      
      Also, a necessity to allocate a contiguous block of vector
      numbers for devices capable of multiple MSIs might cause a
      considerable pressure on x86 interrupt vector allocator and
      could lead to fragmentation of the interrupt vectors space.
      
      This patch overcomes both drawbacks in presense of IRQ remapping
      and lets devices take advantage of multiple queues and per-IRQ
      affinity assignments.
      Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Matthew Wilcox <willy@linux.intel.com>
      Cc: Jeff Garzik <jgarzik@pobox.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/c8bd86ff56b5fc118257436768aaa04489ac0a4c.1353324359.git.agordeev@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      51906e77
  12. 27 11月, 2012 1 次提交
    • S
      x86, apic: Cleanup cfg->domain setup for legacy interrupts · 29c574c0
      Suresh Siddha 提交于
      Issues that need to be handled:
      * Handle PIC interrupts on any CPU irrespective of the apic mode
      * In the apic lowest priority logical flat delivery mode, be prepared to
        handle the interrupt on any CPU irrespective of what the IO-APIC RTE says.
      * Because of above, when the IO-APIC starts handling the legacy PIC interrupt,
        use the same vector that is being used by the PIC while programming the
        corresponding IO-APIC RTE.
      
      Start with all the cpu's in the legacy PIC interrupts cfg->domain.
      
      By the time IO-APIC starts taking over the PIC interrupts, apic driver
      model is finalized. So depend on the assign_irq_vector() to update the
      cfg->domain and retain the same vector that was used by PIC before.
      
      For the logical apic flat mode, cfg->domain is updated (during the first
      call to assign_irq_vector()) to contain all the possible online cpu's (0xff).
      Vector used for the legacy PIC interrupt doesn't change when the IO-APIC
      starts handling the interrupt. Any interrupt migration after that
      doesn't change the cfg->domain or the vector used.
      
      For other apic modes like physical mode, cfg->domain is updated
      (during the first call to assign_irq_vector()) to the boot cpu (cpu-0),
      with the same vector that is being used by the PIC. When that interrupt is
      migrated to a different cpu, cfg->domin and the vector assigned will change
      accordingly.
      Tested-by: NBorislav Petkov <bp@alien8.de>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Link: http://lkml.kernel.org/r/1353970176.21070.51.camel@sbsiddha-desk.sc.intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      29c574c0
  13. 15 11月, 2012 1 次提交
  14. 03 11月, 2012 1 次提交
  15. 24 10月, 2012 1 次提交
    • D
      x86/irq/ioapic: Check for valid irq_cfg pointer in smp_irq_move_cleanup_interrupt · 94777fc5
      Dimitri Sivanich 提交于
      Posting this patch to fix an issue concerning sparse irq's that
      I raised a while back.  There was discussion about adding
      refcounting to sparse irqs (to fix other potential race
      conditions), but that does not appear to have been addressed
      yet.  This covers the only issue of this type that I've
      encountered in this area.
      
      A NULL pointer dereference can occur in
      smp_irq_move_cleanup_interrupt() if we haven't yet setup the
      irq_cfg pointer in the irq_desc.irq_data.chip_data.
      
      In create_irq_nr() there is a window where we have set
      vector_irq in __assign_irq_vector(), but not yet called
      irq_set_chip_data() to set the irq_cfg pointer.
      
      Should an IRQ_MOVE_CLEANUP_VECTOR hit the cpu in question during
      this time, smp_irq_move_cleanup_interrupt() will attempt to
      process the aforementioned irq, but panic when accessing
      irq_cfg.
      
      Only continue processing the irq if irq_cfg is non-NULL.
      Signed-off-by: NDimitri Sivanich <sivanich@sgi.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Joerg Roedel <joerg.roedel@amd.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Alexander Gordeev <agordeev@redhat.com>
      Link: http://lkml.kernel.org/r/20121016125021.GA22935@sgi.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      94777fc5
  16. 15 8月, 2012 1 次提交
    • S
      x86, apic: fix broken legacy interrupts in the logical apic mode · f1c63001
      Suresh Siddha 提交于
      Recent commit 332afa65 cleaned up
      a workaround that updates irq_cfg domain for legacy irq's that
      are handled by the IO-APIC. This was assuming that the recent
      changes in assign_irq_vector() were sufficient to remove the workaround.
      
      But this broke couple of AMD platforms. One of them seems to be
      sending interrupts to the offline cpu's, resulting in spurious
      "No irq handler for vector xx (irq -1)" messages when those cpu's come online.
      And the other platform seems to always send the interrupt to the last logical
      CPU (cpu-7). Recent changes had an unintended side effect of using only logical
      cpu-0 in the IO-APIC RTE (during boot for the legacy interrupts) and this
      broke the legacy interrupts not getting routed to the cpu-7 on the AMD
      platform, resulting in a boot hang.
      
      For now, reintroduce the removed workaround, (essentially not allowing the
      vector to change for legacy irq's when io-apic starts to handle the irq. Which
      also addressed the uninteded sife effect of just specifying cpu-0 in the
      IO-APIC RTE for those irq's during boot).
      Reported-and-tested-by: NRobert Richter <robert.richter@amd.com>
      Reported-and-tested-by: NBorislav Petkov <bp@amd64.org>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Link: http://lkml.kernel.org/r/1344453412.29170.5.camel@sbsiddha-desk.sc.intel.comSigned-off-by: NH. Peter Anvin <hpa@zytor.com>
      f1c63001
  17. 26 7月, 2012 1 次提交
    • T
      x86/ioapic: Fix NULL pointer dereference on CPU hotplug after disabling irqs · 1d44b30f
      Tomoki Sekiyama 提交于
      In the current kernel, percpu variable `vector_irq' is not always
      cleared when a CPU is offlined. If the CPU that has the disabled
      irqs in vector_irq is hotplugged again, __setup_vector_irq()
      hits invalid irq vector and may crash.
      
      This bug can be reproduced as following;
      
       # echo 0 > /sys/devices/system/cpu/cpu7/online
       # modprobe -r some_driver_using_interrupts     # vector_irq@cpu7 uncleared
       # echo 1 > /sys/devices/system/cpu/cpu7/online # kernel may crash
      
      To fix this problem, this patch clears vector_irq in
      __fixup_irqs() when the CPU is offlined.
      
      This also reverts commit f6175f5b, which partially fixes
      this bug by clearing vector in __clear_irq_vector(). But in
      environments with IOMMU IRQ remapper, it could fail because
      cfg->domain doesn't contain offlined CPUs. With this patch, the
      fix in __clear_irq_vector() can be reverted because every
      vector_irq is already cleared in __fixup_irqs() on offlined CPUs.
      Signed-off-by: NTomoki Sekiyama <tomoki.sekiyama.qu@hitachi.com>
      Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: yrl.pp-manager.tt@hitachi.com
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Alexander Gordeev <agordeev@redhat.com>
      Link: http://lkml.kernel.org/r/20120726104732.2889.19144.stgit@kvmdevSigned-off-by: NIngo Molnar <mingo@kernel.org>
      1d44b30f
  18. 06 7月, 2012 2 次提交
  19. 15 6月, 2012 1 次提交
  20. 14 6月, 2012 1 次提交
  21. 08 6月, 2012 2 次提交
    • A
      x86/apic: Make cpu_mask_to_apicid() operations return error code · ff164324
      Alexander Gordeev 提交于
      Current cpu_mask_to_apicid() and cpu_mask_to_apicid_and()
      implementations have few shortcomings:
      
      1. A value returned by cpu_mask_to_apicid() is written to
      hardware registers unconditionally. Should BAD_APICID get ever
      returned it will be written to a hardware too. But the value of
      BAD_APICID is not universal across all hardware in all modes and
      might cause unexpected results, i.e. interrupts might get routed
      to CPUs that are not configured to receive it.
      
      2. Because the value of BAD_APICID is not universal it is
      counter- intuitive to return it for a hardware where it does not
      make sense (i.e. x2apic).
      
      3. cpu_mask_to_apicid_and() operation is thought as an
      complement to cpu_mask_to_apicid() that only applies a AND mask
      on top of a cpumask being passed. Yet, as consequence of 18374d89
      commit the two operations are inconsistent in that of:
        cpu_mask_to_apicid() should not get a offline CPU with the cpumask
        cpu_mask_to_apicid_and() should not fail and return BAD_APICID
      These limitations are impossible to realize just from looking at
      the operations prototypes.
      
      Most of these shortcomings are resolved by returning a error
      code instead of BAD_APICID. As the result, faults are reported
      back early rather than possibilities to cause a unexpected
      behaviour exist (in case of [1]).
      
      The only exception is setup_timer_IRQ0_pin() routine. Although
      obviously controversial to this fix, its existing behaviour is
      preserved to not break the fragile check_timer() and would
      better addressed in a separate fix.
      Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
      Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/20120607131559.GF4759@dhcp-26-207.brq.redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      ff164324
    • A
      x86/apic: Avoid useless scanning thru a cpumask in assign_irq_vector() · 8637e38a
      Alexander Gordeev 提交于
      In case of static vector allocation domains (i.e. flat) if all
      vector numbers are exhausted, an attempt to assign a new vector
      will lead to useless scans through all CPUs in the cpumask, even
      though it is known that each new pass would fail. Make this
      corner case less painful by letting report whether the vector
      allocation domain depends on passed arguments or not and stop
      scanning early.
      
      The same could have been achived by introducing a static flag to
      the apic operations. But let's allow vector_allocation_domain()
      have more intelligence here and decide dynamically, in case we
      would need it in the future.
      Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
      Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/20120607131542.GE4759@dhcp-26-207.brq.redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      8637e38a