From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: Preventing IPI sending races in arch code Date: Tue, 26 Nov 2013 16:11:01 +1100 Message-ID: <1385442661.9218.51.camel@pasglop> References: <52932BE2.5010201@synopsys.com> <20131125110006.GU3866@twins.programming.kicks-ass.net> <529334CA.1000401@synopsys.com> <20131125122726.GZ10022@twins.programming.kicks-ass.net> <1385409103.9218.15.camel@pasglop> <529427F1.2080409@synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from gate.crashing.org ([63.228.1.57]:55967 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750937Ab3KZFM1 (ORCPT ); Tue, 26 Nov 2013 00:12:27 -0500 In-Reply-To: <529427F1.2080409@synopsys.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Vineet Gupta Cc: Peter Zijlstra , "linux-arch@vger.kernel.org" , Gilad Ben-Yossef , Noam Camus , David Daney , James Hogan , thomas Gleixner , lkml , Richard Kuo On Tue, 2013-11-26 at 10:17 +0530, Vineet Gupta wrote: > On 11/26/2013 01:21 AM, Benjamin Herrenschmidt wrote: > > On Mon, 2013-11-25 at 13:35 +0000, Vineet Gupta wrote: > > > >> Before reading ur email I was coding something like below: > >> > >> void arch_send_ipi(int cpu, int type) > >> { > >> u32 *pending_ptr = per_cpu_ptr(ipi_bits, cpu); > >> > >> while (cmpxchg(pending_ptr, 0, 1 << type) != 0) > >> cpu_relax(); > >> > >> raise_ipi(cpu); > >> } > > > > So you would have blocked the sender while there was already > > a pending IPI on the target ? Why ? > > A simplistic (but non optimal) way to cater to the race where 2 senders try to > send the exact same msg to same receiver. Upon first IPI, receiver "consumes" the > msg (using xchg with 0) so the 2nd IPI seems "empty" i.e. no msg. But there is no race... > > The optimization proposed by Peter is actually the only interesting > > change here, without it the existing set_bit was perfectly fine. > > I'm not sure, see below. > > > Remember that set_bit is atomic. > > Right, but the issue per-se is not clobbering of msg holder, but from POV of > receiver, seeming coalescing of 2 set_bit writes to msg holder. That's fine. There's no expectation that N ipi_send_msg turn into N messages received... it turns into at least one. Just like MSIs or other edge interrupts Cheers, Ben. > core0 core1 core2 > > set_bit 1 > kick IPI-2 set_bit 1 IPI-0 received > kick IPI-2 read+clear bit > IPI-1 received > no msg > > -Vineet > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/