kernel/linux.git/drivers/irqchip, branch v3.18.62

irqchip/gic-v3: Fix out-of-bound access in gic_set_affinity

2017-07-21T06:12:22+00:00

commit 866d7c1b0a3c70387646c4e455e727a58c5d465a upstream. The GICv3 driver doesn't check if the target CPU for gic_set_affinity is valid before going ahead and making the changes. This triggers the following splat with KASAN: [ 141.189434] BUG: KASAN: global-out-of-bounds in gic_set_affinity+0x8c/0x140 [ 141.189704] Read of size 8 at addr ffff200009741d20 by task swapper/1/0 [ 141.189958] [ 141.190158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.12.0-rc7 [ 141.190458] Hardware name: Foundation-v8A (DT) [ 141.190658] Call trace: [ 141.190908] [] dump_backtrace+0x0/0x328 [ 141.191224] [] show_stack+0x14/0x20 [ 141.191507] [] dump_stack+0xa4/0xc8 [ 141.191858] [] print_address_description+0x13c/0x250 [ 141.192219] [] kasan_report+0x210/0x300 [ 141.192547] [] __asan_load8+0x84/0x98 [ 141.192874] [] gic_set_affinity+0x8c/0x140 [ 141.193158] [] irq_do_set_affinity+0x54/0xb8 [ 141.193473] [] irq_set_affinity_locked+0x64/0xf0 [ 141.193828] [] __irq_set_affinity+0x48/0x78 [ 141.194158] [] arm_perf_starting_cpu+0x104/0x150 [ 141.194513] [] cpuhp_invoke_callback+0x17c/0x1f8 [ 141.194783] [] notify_cpu_starting+0x8c/0xb8 [ 141.195130] [] secondary_start_kernel+0x15c/0x200 [ 141.195390] [<0000000080db81b4>] 0x80db81b4 [ 141.195603] [ 141.195685] The buggy address belongs to the variable: [ 141.196012] __cpu_logical_map+0x200/0x220 [ 141.196176] [ 141.196315] Memory state around the buggy address: [ 141.196586] ffff200009741c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 141.196913] ffff200009741c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 141.197158] >ffff200009741d00: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 00 [ 141.197487] ^ [ 141.197758] ffff200009741d80: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00 [ 141.198060] ffff200009741e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 141.198358] ================================================================== [ 141.198609] Disabling lock debugging due to kernel taint [ 141.198961] CPU1: Booted secondary processor [410fd051] This patch adds the check to make sure the cpu is valid. Fixes: commit 021f653791ad17e03f98 ("irqchip: gic-v3: Initial support for GICv3") Signed-off-by: Suzuki K Poulose Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman

irqchip/gicv3: Handle loop timeout proper

2016-11-24T02:28:50+00:00

[ Upstream commit d102eb5c1ac5e6743b1c6d145c06a25d98ad1375 ] The timeout loop terminates when the loop count is zero, but the decrement of the count variable is post check. So count is -1 when we check for the timeout and therefor the error message is supressed. Change it to predecrement, so the error message is emitted. [ tglx: Massaged changelog ] Fixes: a2c225101234 ("irqchip: gic-v3: Refactor gic_enable_redist to support both enabling and disabling") Signed-off-by: Dan Carpenter Acked-by: Sudeep Holla Cc: Marc Zyngier Cc: kernel-janitors@vger.kernel.org Cc: Jason Cooper Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20161014072534.GA15168@mwanda Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin

genirq: Generic chip: Change irq_reg_{readl,writel} arguments

2016-10-06T02:40:20+00:00

[ Upstream commit 332fd7c4fef5f3b166e93decb07fd69eb24f7998 ] Pass in the irq_chip_generic struct so we can use different readl/writel settings for each irqchip driver, when appropriate. Compute (gc->reg_base + reg_offset) in the helper function because this is pretty much what all callers want to do anyway. Compile-tested using the following configurations: at91_dt_defconfig (CONFIG_ATMEL_AIC_IRQ=y) sama5_defconfig (CONFIG_ATMEL_AIC5_IRQ=y) sunxi_defconfig (CONFIG_ARCH_SUNXI=y) tb10x (ARC) is untested. Signed-off-by: Kevin Cernekee Acked-by: Thomas Gleixner Acked-by: Acked-by: Arnd Bergmann Link: https://lkml.kernel.org/r/1415342669-30640-3-git-send-email-cernekee@gmail.com Signed-off-by: Jason Cooper Signed-off-by: Sasha Levin

arm64: GICv3: introduce symbolic names for GICv3 ICC_SGI1R_EL1 fields

2016-06-20T03:47:43+00:00

[ Upstream commit 7e5802781c3e109558ddfd8b02155ad24d872ee7 ] The gic_send_sgi() function used hardcoded bit shift values to generate the ICC_SGI1R_EL1 register value. Replace this with symbolic names to allow reusing them later. Signed-off-by: Andre Przywara Reviewed-by: Christoffer Dall Signed-off-by: Christoffer Dall Signed-off-by: Sasha Levin

irqchip/gic: Ensure ordering between read of INTACK and shared data

2016-06-06T23:11:02+00:00

[ Upstream commit f86c4fbd930ff6fecf3d8a1c313182bd0f49f496 ] When an IPI is generated by a CPU, the pattern looks roughly like: smp_wmb(); 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: Will Deacon Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin

irqchip/omap-intc: Add support for spurious irq handling

2016-04-12T13:07:31+00:00

[ Upstream commit d3b421cd07e4c0d4d6c0bbd55ca169c054fc081d ] Under some conditions, irq sorting procedure used by INTC can go wrong resulting in a spurious irq getting reported. If this condition is not handled, it results in endless stream of: unexpected IRQ trap at vector 00 messages from ack_bad_irq() Handle the spurious interrupt condition in omap-intc driver to prevent this. Measurements using kernel function profiler on AM335x EVM running at 720MHz show that after this patch omap_intc_handle_irq() takes about 37.4us against 34us before this patch. Signed-off-by: Sekhar Nori Acked-by: Tony Lindgren Cc: John Ogness Cc: Felipe Balbi Cc: Jason Cooper Cc: Marc Zyngier Link: http://lkml.kernel.org/r/9c78a6db02ac55f7af7371b417b6e414d2c3095b.1450188128.git.nsekhar@ti.com Cc: stable@vger.kernel.org Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin

irqchip: omap-intc: Improve IRQ handler

2016-04-12T13:07:22+00:00

[ Upstream commit 6ed3464897cc825a75218653c710d673282dfcf8 ] As it turns out the current IRQ number will *always* be available from SIR register which renders the reads of PENDING registers as plain unnecessary overhead. In order to catch any situation where SIR reads as zero, we're adding a WARN() to turn it into a very verbose error and users actually report it. With this patch average running time of omap_intc_handle_irq() reduced from about 28.5us to 19.8us as measured by the kernel function profiler. Tested with BeagleBoneBlack Rev A5C. Tested-by: Tony Lindgren Signed-off-by: Felipe Balbi Cc: Linux ARM Kernel Mailing List Link: http://lkml.kernel.org/r/20150720204910.GH5394@saruman.tx.rr.com Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin

irqchip/atmel-aic: Fix wrong bit operation for IRQ priority

2016-02-15T20:42:33+00:00

[ Upstream commit 49f34134aea74f19ca016f055d25ee55ec359dee ] Atmel AIC has common structure for SMR (Source Mode Register). bit[6:5] Interrupt source type bit[2:0] Priority level Other bits are unused. To update new priority value, bit[2:0] should be cleared first and then new priority level can be written. However, aic_common_set_priority() helper clears source type bits instead of priority bits. This patch fixes wrong mask bit operation. Fixes: b1479ebb7720 "irqchip: atmel-aic: Add atmel AIC/AIC5 drivers" Signed-off-by: Milo Kim Acked-by: Boris Brezillon Cc: Jason Cooper Cc: Marc Zyngier Cc: Ludovic Desroches Cc: Nicholas Ferre Cc: stable@vger.kernel.org #v3.17+ Link: http://lkml.kernel.org/r/1452669592-3401-2-git-send-email-milo.kim@ti.com Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin

irqchip: sunxi-nmi: Fix off-by-one error in irq iterator

2015-07-03T16:34:47+00:00

[ Upstream commit febe06962ab191db50e633a0f79d9fb89a2d1078 ] Fixes: 6058bb362818 'ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller' Signed-off-by: Axel Lin Cc: Maxime Ripard Cc: Carlo Caione Cc: Jason Cooper Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1433684009.9134.1.camel@ingics.com Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin

irqchip: armada-370-xp: Fix chained per-cpu interrupts

2015-03-28T14:03:20+00:00

[ Upstream commit 5724be8464dceac047c1eaddaa3651cea0ec16ca ] On the Cortex-A9-based Armada SoCs, the MPIC is not the primary interrupt controller. Yet, it still has to handle some per-cpu interrupt. To do so, it is chained with the GIC using a per-cpu interrupt. However, the current code only call irq_set_chained_handler, which is called and enable that interrupt only on the boot CPU, which means that the parent per-CPU interrupt is never unmasked on the secondary CPUs, preventing the per-CPU interrupt to actually work as expected. This was not seen until now since the only MPIC PPI users were the Marvell timers that were not working, but not used either since the system use the ARM TWD by default, and the ethernet controllers, that are faking there interrupts as SPI, and don't really expect to have interrupts on the secondary cores anyway. Add a CPU notifier that will enable the PPI on the secondary cores when they are brought up. Cc: # 3.15+ Signed-off-by: Maxime Ripard Acked-by: Gregory CLEMENT Link: https://lkml.kernel.org/r/1425378443-28822-1-git-send-email-maxime.ripard@free-electrons.com Signed-off-by: Jason Cooper Signed-off-by: Sasha Levin