1. 11 5月, 2016 2 次提交
    • M
      irqchip/gic-v3: Configure all interrupts as non-secure Group-1 · 7c9b9730
      Marc Zyngier 提交于
      The GICv3 driver wrongly assumes that it runs on the non-secure
      side of a secure-enabled system, while it could be on a system
      with a single security state, or a GICv3 with GICD_CTLR.DS set.
      
      Either way, it is important to configure this properly, or
      interrupts will simply not be delivered on this HW.
      
      Cc: stable@vger.kernel.org
      Reported-by: NPeter Maydell <peter.maydell@linaro.org>
      Tested-by: NPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      7c9b9730
    • W
      irqchip/gic: Ensure ordering between read of INTACK and shared data · f86c4fbd
      Will Deacon 提交于
      When an IPI is generated by a CPU, the pattern looks roughly like:
      
        <write shared data>
        smp_wmb();
        <write to GIC to signal SGI>
      
      On the receiving CPU we rely on the fact that, once we've taken the
      interrupt, then the freshly written shared data must be visible to us.
      Put another way, the CPU isn't going to speculate taking an interrupt.
      
      Unfortunately, this assumption turns out to be broken.
      
      Consider that CPUx wants to send an IPI to CPUy, which will cause CPUy
      to read some shared_data. Before CPUx has done anything, a random
      peripheral raises an IRQ to the GIC and the IRQ line on CPUy is raised.
      CPUy then takes the IRQ and starts executing the entry code, heading
      towards gic_handle_irq. Furthermore, let's assume that a bunch of the
      previous interrupts handled by CPUy were SGIs, so the branch predictor
      kicks in and speculates that irqnr will be <16 and we're likely to
      head into handle_IPI. The prefetcher then grabs a speculative copy of
      shared_data which contains a stale value.
      
      Meanwhile, CPUx gets round to updating shared_data and asking the GIC
      to send an SGI to CPUy. Internally, the GIC decides that the SGI is
      more important than the peripheral interrupt (which hasn't yet been
      ACKed) but doesn't need to do anything to CPUy, because the IRQ line
      is already raised.
      
      CPUy then reads the ACK register on the GIC, sees the SGI value which
      confirms the branch prediction and we end up with a stale shared_data
      value.
      
      This patch fixes the problem by adding an smp_rmb() to the IPI entry
      code in gic_handle_irq. As it turns out, the combination of a control
      dependency and an ISB instruction from the EOI in the GICv3 driver is
      enough to provide the ordering we need, so we add a comment there
      justifying the absence of an explicit smp_rmb().
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      f86c4fbd
  2. 03 5月, 2016 3 次提交
  3. 02 5月, 2016 1 次提交
  4. 09 3月, 2016 4 次提交
  5. 15 10月, 2015 1 次提交
  6. 14 10月, 2015 2 次提交
  7. 10 10月, 2015 4 次提交
  8. 29 9月, 2015 2 次提交
  9. 16 9月, 2015 2 次提交
    • R
      irqchip: Kill off set_irq_flags usage · d17cab44
      Rob Herring 提交于
      set_irq_flags is ARM specific with custom flags which have genirq
      equivalents. Convert drivers to use the genirq interfaces directly, so we
      can kill off set_irq_flags. The translation of flags is as follows:
      
      IRQF_VALID -> !IRQ_NOREQUEST
      IRQF_PROBE -> !IRQ_NOPROBE
      IRQF_NOAUTOEN -> IRQ_NOAUTOEN
      
      For IRQs managed by an irqdomain, the irqdomain core code handles clearing
      and setting IRQ_NOREQUEST already, so there is no need to do this in
      .map() functions and we can simply remove the set_irq_flags calls. Some
      users also modify IRQ_NOPROBE and this has been maintained although it
      is not clear that is really needed. There appears to be a great deal of
      blind copy and paste of this code.
      Signed-off-by: NRob Herring <robh@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Kukjin Kim <kgene@kernel.org>
      Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Lee Jones <lee@kernel.org>
      Cc: Alexander Shiyan <shc_work@mail.ru>
      Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
      Cc: linux-rpi-kernel@lists.infradead.org
      Cc: linux-samsung-soc@vger.kernel.org
      Link: http://lkml.kernel.org/r/1440889285-5637-3-git-send-email-robh@kernel.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      d17cab44
    • T
      irqchip/gic-v3: Use IRQD_FORWARDED_TO_VCPU flag · 4df7f54d
      Thomas Gleixner 提交于
      Get rid of the handler_data abuse.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      4df7f54d
  10. 27 8月, 2015 2 次提交
  11. 12 7月, 2015 1 次提交
  12. 06 6月, 2015 1 次提交
  13. 09 4月, 2015 1 次提交
  14. 08 3月, 2015 1 次提交
    • V
      irqchip: gic-v3: Fix out of bounds access to cpu_logical_map · 614be385
      Vladimir Murzin 提交于
      While playing with KASan support for arm64/arm the following appeared on boot:
      
      ==================================================================
      BUG: AddressSanitizer: out of bounds access in __asan_load8+0x14/0x1c at addr ffffffc000ad0dc0
      Read of size 8 by task swapper/0/1
      page:ffffffbdc202b400 count:1 mapcount:0 mapping:          (null) index:0x0
      flags: 0x400(reserved)
      page dumped because: kasan: bad access detected
      Address belongs to variable __cpu_logical_map+0x200/0x220
      CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc6-next-20150129+ #481
      Hardware name: FVP Base (DT)
      Call trace:
      [<ffffffc00008a794>] dump_backtrace+0x0/0x184
      [<ffffffc00008a928>] show_stack+0x10/0x1c
      [<ffffffc00075e46c>] dump_stack+0xa0/0xf8
      [<ffffffc0001df490>] kasan_report_error+0x23c/0x264
      [<ffffffc0001e0188>] check_memory_region+0xc0/0xe4
      [<ffffffc0001dedf0>] __asan_load8+0x10/0x1c
      [<ffffffc000431294>] gic_raise_softirq+0xc4/0x1b4
      [<ffffffc000091fc0>] smp_send_reschedule+0x30/0x3c
      [<ffffffc0000f0d1c>] try_to_wake_up+0x394/0x434
      [<ffffffc0000f0de8>] wake_up_process+0x2c/0x6c
      [<ffffffc0000d9570>] wake_up_worker+0x38/0x48
      [<ffffffc0000dbb50>] insert_work+0xac/0xec
      [<ffffffc0000dbd38>] __queue_work+0x1a8/0x374
      [<ffffffc0000dbf60>] queue_work_on+0x5c/0x7c
      [<ffffffc0000d8a78>] call_usermodehelper_exec+0x170/0x188
      [<ffffffc0004037b8>] kobject_uevent_env+0x650/0x6bc
      [<ffffffc000403830>] kobject_uevent+0xc/0x18
      [<ffffffc00040292c>] kset_register+0xa8/0xc8
      [<ffffffc0004d6c88>] bus_register+0x134/0x2e8
      [<ffffffc0004d73b4>] subsys_virtual_register+0x2c/0x5c
      [<ffffffc000a76a4c>] wq_sysfs_init+0x14/0x20
      [<ffffffc000082a28>] do_one_initcall+0xa8/0x1fc
      [<ffffffc000a70db4>] kernel_init_freeable+0x1ec/0x294
      [<ffffffc00075aa5c>] kernel_init+0xc/0xec
      Memory state around the buggy address:
       ffffff80003e0820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffffff80003e0830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      >ffffff80003e0840: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
                         ^
       ffffff80003e0850: 00 00 fa fa fa fa fa fa 00 00 00 00 00 00 00 00
      ==================================================================
      
      The reason for that cpumask_next() returns >= nr_cpu_ids if no further cpus
      set, but "==" condition is checked only, so we end up with out-of-bounds
      access to cpu_logical_map.
      
      Fix is by using the condition check for cpumask_next.
      Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Link: https://lkml.kernel.org/r/1425659870-11832-7-git-send-email-marc.zyngier@arm.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>
      614be385
  15. 05 3月, 2015 1 次提交
  16. 26 1月, 2015 1 次提交
  17. 21 1月, 2015 1 次提交
  18. 26 11月, 2014 3 次提交
  19. 14 9月, 2014 2 次提交
  20. 03 9月, 2014 2 次提交
  21. 18 8月, 2014 2 次提交
  22. 25 7月, 2014 1 次提交