ARCv2: SMP: Emulate IPI to self using software triggered interrupt
authorVineet Gupta <vgupta@synopsys.com>
Tue, 23 Feb 2016 06:25:16 +0000 (11:55 +0530)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 3 Mar 2016 23:07:28 +0000 (15:07 -0800)
commit1de8f1bcb5321bdc35b64bafe4f4a9c389942167
treedd40944c2a7889115ebe547b0ce71bdaf15e7d90
parent0bdce40ce0402ab4d46e33f452eb0c29470e0dc6
ARCv2: SMP: Emulate IPI to self using software triggered interrupt

commit bb143f814ea488769ca2e79e0b376139cb5f134b upstream.

ARConnect/MCIP Inter-Core-Interrupt module can't send interrupt to
local core. So use core intc capability to trigger software
interrupt to self, using an unsued IRQ #21.

This showed up as csd deadlock with LTP trace_sched on a dual core
system. This test acts as scheduler fuzzer, triggering all sorts of
schedulting activity. Trouble starts with IPI to self, which doesn't get
delivered (effectively lost due to H/w capability), but the msg intended
to be sent remain enqueued in per-cpu @ipi_data.

All subsequent IPIs to this core from other cores get elided due to the
IPI coalescing optimization in ipi_send_msg_one() where a pending msg
implies an IPI already sent and assumes other core is yet to ack it.
After the elided IPI, other core simply goes into csd_lock_wait()
but never comes out as this core never sees the interrupt.

Fixes STAR 9001008624

Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arch/arc/include/asm/irqflags-arcv2.h
arch/arc/kernel/entry-arcv2.S
arch/arc/kernel/mcip.c