From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhVLn-0005EC-7K for qemu-devel@nongnu.org; Wed, 07 Sep 2016 01:24:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhVLi-00029b-J0 for qemu-devel@nongnu.org; Wed, 07 Sep 2016 01:24:43 -0400 Message-ID: <1473225857.8689.62.camel@kernel.crashing.org> From: Benjamin Herrenschmidt Date: Wed, 07 Sep 2016 15:24:17 +1000 In-Reply-To: <87d1kgjoy9.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me> 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> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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: Nikunj A Dadhania , David Gibson Cc: qemu-ppc@nongnu.org, alex.bennee@linaro.org, rth@twiddle.net, qemu-devel@nongnu.org On Wed, 2016-09-07 at 10:17 +0530, Nikunj A Dadhania wrote: > > David Gibson writes: >=20 > >=20 > > [ Unknown signature status ] > > On Fri, Sep 02, 2016 at 12:02:55PM +0530, Nikunj A Dadhania wrote: > > >=20 > > > > > > Signed-off-by: Nikunj A Dadhania > >=20 > > This really needs a comment indicating that this implementation isn't > > strictly correct (although probably good enough in practice). >=20 > Sure. And it also does not help if someone uses any store other than > store conditional, that isn't taken care. >=20 > Assumption here is the locking primitives use load with reservation and > store conditional. And no other ld/st variant touch this memory. This is an incorrect assumption. spin_unlock for example uses a normal store. That being said, you will observe the difference in value which should hopefully make things work... I *hope* we don't have anything that relies on a normal store of the same value as the atomic breaking the reservation, I *think* we might get away with it, but it is indeed fishy. > > 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. > >=20 > > 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.=C2=A0=C2=A0So,= this is > > probably a reasonable substitute, but we should note the fact that > > it's not 100%. >=20 > I will update the commit log. >=20 > Regards, > Nikunj