From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhX3C-0000Uu-8R for qemu-devel@nongnu.org; Wed, 07 Sep 2016 03:13:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhX38-0007Ha-0I for qemu-devel@nongnu.org; Wed, 07 Sep 2016 03:13:37 -0400 Received: from mail-wm0-x232.google.com ([2a00:1450:400c:c09::232]:38181) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhX37-0007HD-HL for qemu-devel@nongnu.org; Wed, 07 Sep 2016 03:13:33 -0400 Received: by mail-wm0-x232.google.com with SMTP id 1so14521141wmz.1 for ; Wed, 07 Sep 2016 00:13:33 -0700 (PDT) References: <1472797976-24210-1-git-send-email-nikunj@linux.vnet.ibm.com> <1472797976-24210-4-git-send-email-nikunj@linux.vnet.ibm.com> <20160907040252.GJ2780@voom.fritz.box> <87d1kgjoy9.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me> <20160907053459.GM2780@voom.fritz.box> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <20160907053459.GM2780@voom.fritz.box> Date: Wed, 07 Sep 2016 08:13:31 +0100 Message-ID: <87d1kgyyg4.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH RFC 3/4] target-ppc: use atomic_cmpxchg for ld/st reservation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: Nikunj A Dadhania , qemu-ppc@nongnu.org, rth@twiddle.net, qemu-devel@nongnu.org, benh@kernel.crashing.org David Gibson writes: > On Wed, Sep 07, 2016 at 10:17:42AM +0530, Nikunj A Dadhania wrote: >> David Gibson writes: >> >> > [ Unknown signature status ] >> > On Fri, Sep 02, 2016 at 12:02:55PM +0530, Nikunj A Dadhania wrote: >> >> Signed-off-by: Nikunj A Dadhania >> > >> > This really needs a comment indicating that this implementation isn't >> > strictly correct (although probably good enough in practice). >> >> Sure. And it also does not help if someone uses any store other than >> store conditional, that isn't taken care. >> >> Assumption here is the locking primitives use load with reservation and >> store conditional. And no other ld/st variant touch this memory. > > So, a) I don't think this really relies on that: an ordinary store > (assuming it changes the value) will still get picked up the cmpxchg. > Well.. at least after a suitable memory barrier. Matching memory > models between emulated and host cpus is a whole other kettle of fish. Have you seen Pranith's memory barrier patches? > > I think this does matter, IIRC a kernel spin unlock on ppc is a > barrier + plain store, no load locked or store conditional. > >> > Specifically a racing store which happens to store the same value >> > which was already in memory should clobber the reservation, but won't >> > with this implementation. >> > >> > I had a long discussion at KVM Forum with Emilio Costa about this, in >> > which I discovered just how hard it is to strictly implement >> > store-conditional semantics in terms of anything else. So, this is >> > probably a reasonable substitute, but we should note the fact that >> > it's not 100%. >> >> I will update the commit log. >> >> Regards, >> Nikunj >> -- Alex Bennée