1. 22 4月, 2016 1 次提交
    • P
      irqchip/mips-gic: Don't overrun pcpu_masks array · 91951f98
      Paul Burton 提交于
      Commit 2a078705 ("irqchip/mips-gic: Use gic_vpes instead of
      NR_CPUS") & commit 78930f09 ("irqchip/mips-gic: Clear percpu_masks
      correctly when mapping") both introduce code which accesses gic_vpes
      entries in the pcpu_masks array. However, this array has length NR_CPUS.
      If NR_CPUS is less than gic_vpes (ie. the kernel supports use of less
      CPUs than are present in the system) then we overrun the array, clobber
      some other data & generally die pretty promptly.
      
      Most notably this affects uniprocessor kernels running on any multicore
      or multithreaded Malta with a GIC (ie. the vast majority of real Malta
      boards).
      
      Fix this by only accessing up to min(gic_vpes, NR_CPUS) entries in the
      pcpu_masks array, preventing the array overrun.
      
      Fixes: 2a078705 ("irqchip/mips-gic: Use gic_vpes instead of NR_CPUS")
      Fixes: 78930f09 ("irqchip/mips-gic: Clear percpu_masks correctly when mapping")
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Link: http://lkml.kernel.org/r/1461234714-9975-1-git-send-email-paul.burton@imgtec.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      91951f98
  2. 23 3月, 2016 1 次提交
  3. 21 3月, 2016 2 次提交
  4. 11 3月, 2016 1 次提交
  5. 10 3月, 2016 2 次提交
  6. 09 3月, 2016 8 次提交
  7. 25 2月, 2016 6 次提交
  8. 19 2月, 2016 2 次提交
  9. 18 2月, 2016 6 次提交
  10. 17 2月, 2016 8 次提交
  11. 12 2月, 2016 1 次提交
    • A
      irqchip/gic-v3-its: Fix double ICC_EOIR write for LPI in EOImode==1 · 004fa08d
      Ashok Kumar 提交于
      When the GIC is using EOImode==1, the EOI is done immediately,
      leaving the deactivation to be performed when the EOI was
      previously done.
      
      Unfortunately, the ITS is not aware of the EOImode at all, and
      blindly EOIs the interrupt again. On most systems, this is ignored
      (despite being a programming error), but some others do raise a
      SError exception as there is no priority drop to perform for this
      interrupt.
      
      The fix is to stop trying to be clever, and always call into the
      underlying GIC to perform the right access, irrespective of the
      more we're in.
      
      [Marc: Reworked commit message]
      
      Fixes: 0b996fd3 ("irqchip/GICv3: Convert to EOImode == 1")
      Cc: stable@vger.kernel.org
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NAshok Kumar <ashoks@broadcom.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      004fa08d
  12. 11 2月, 2016 2 次提交