Re: [PATCH] x86 spinlock: Fix memory corruption on completing completions

From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM list <kvm@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	Peter Anvin <hpa@zytor.com>, Andi Kleen <ak@linux.intel.com>,
	Andrey Ryabinin <a.ryabinin@samsung.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	xen-devel@lists.xenproject.org,
	Paul McKenney <paulmck@linux.vnet.ibm.com>,
	Rik van Riel <riel@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Sasha Levin <sasha.levin@oracle.com>,
	Dave Jones <davej@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	virtualization <virtualization@lists.linux-foundation.org>,
	Waiman Long <waiman.long@hp.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86 spinlock: Fix memory corruption on completing completions
Date: Wed, 11 Feb 2015 23:08:03 -0800	[thread overview]
Message-ID: <54DC5153.6070403@goop.org> (raw)
In-Reply-To: <CA+55aFwnCxUV2JrWkq0pMtymzTfVetYd_NRKn4SB4fXqU5qZ8w@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 1003 bytes --]

On 02/11/2015 03:28 PM, Linus Torvalds wrote:
>
>
> On Feb 11, 2015 3:15 PM, "Jeremy Fitzhardinge" <jeremy@goop.org
> <mailto:jeremy@goop.org>> wrote:
> >
> > Right now it needs to be a locked operation to prevent read-reordering.
> > x86 memory ordering rules state that all writes are seen in a globally
> > consistent order, and are globally ordered wrt reads *on the same
> > addresses*, but reads to different addresses can be reordered wrt to
> writes.
>
> The modern x86 rules are actually much tighter than that.
>
> Every store is a release, and every load is an acquire. So a
> non-atomic store is actually a perfectly fine unlock. All preceding
> stores will be seen by other cpu's before the unlock, and while reads
> can pass stores, they only pass *earlier* stores.
>

Right, so in this particular instance, the read of the SLOWPATH flag
*can't* pass the previous unlock store, hence the need for an atomic
unlock or some other mechanism to prevent the read from being reordered.

    J

[-- Attachment #1.2: Type: text/html, Size: 1704 bytes --]

[-- Attachment #2: Type: text/plain, Size: 183 bytes --]

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization