summaryrefslogtreecommitdiffstats
path: root/drivers/irqchip
diff options
context:
space:
mode:
authorWill Deacon <will.deacon@arm.com>2016-04-26 12:00:00 +0100
committerBen Hutchings <ben@decadent.org.uk>2016-08-22 22:37:57 +0100
commite30364e00b5b83889deb635dcc51339da6d1da7a (patch)
treeceb92e6b51686aed1dfef3d348b54f5fa9d91d17 /drivers/irqchip
parent62582a66d5d3f436cfae65052f6c2a97f5a23c2b (diff)
downloadlinux-stable-e30364e00b5b83889deb635dcc51339da6d1da7a.tar.gz
linux-stable-e30364e00b5b83889deb635dcc51339da6d1da7a.tar.bz2
linux-stable-e30364e00b5b83889deb635dcc51339da6d1da7a.zip
irqchip/gic: Ensure ordering between read of INTACK and shared data
commit f86c4fbd930ff6fecf3d8a1c313182bd0f49f496 upstream. 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(). Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> [bwh: Backported to 3.16: drop changes to irq-gic-v3] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Diffstat (limited to 'drivers/irqchip')
-rw-r--r--drivers/irqchip/irq-gic.c8
1 files changed, 8 insertions, 0 deletions
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 7c131cf7cc13..605e65713093 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -302,6 +302,14 @@ static void __exception_irq_entry gic_handle_irq(struct pt_regs *regs)
if (irqnr < 16) {
writel_relaxed(irqstat, cpu_base + GIC_CPU_EOI);
#ifdef CONFIG_SMP
+ /*
+ * Ensure any shared data written by the CPU sending
+ * the IPI is read after we've read the ACK register
+ * on the GIC.
+ *
+ * Pairs with the write barrier in gic_raise_softirq
+ */
+ smp_rmb();
handle_IPI(irqnr, regs);
#endif
continue;