From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH] x86 spinlock: Fix memory corruption on completing completions Date: Wed, 11 Feb 2015 23:08:03 -0800 Message-ID: <54DC5153.6070403@goop.org> References: <1423234148-13886-1-git-send-email-raghavendra.kt@linux.vnet.ibm.com> <54D7D19B.1000103@goop.org> <54D87F1E.9060307@linux.vnet.ibm.com> <20150209120227.GT21418@twins.programming.kicks-ass.net> <54D9CFC7.5020007@linux.vnet.ibm.com> <20150210132634.GA30380@redhat.com> <54DAADEE.6070506@goop.org> <20150211172434.GA28689@redhat.com> <54DBE27C.8050105@goop.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8975782560207666258==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Linus Torvalds Cc: Raghavendra K T , KVM list , Peter Zijlstra , Oleg Nesterov , Paul Gortmaker , Peter Anvin , Andi Kleen , Andrey Ryabinin , the arch/x86 maintainers , Christian Borntraeger , Ingo Molnar , xen-devel@lists.xenproject.org, Paul McKenney , Rik van Riel , Konrad Rzeszutek Wilk , Davidlohr Bueso , Sasha Levin , Dave Jones , Thomas Gleixner , virtualization , Waiman Long , Linux Kernel Mailing List List-Id: virtualization@lists.linuxfoundation.org This is a multi-part message in MIME format. --===============8975782560207666258== Content-Type: multipart/alternative; boundary="------------080003000807090708020906" This is a multi-part message in MIME format. --------------080003000807090708020906 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 02/11/2015 03:28 PM, Linus Torvalds wrote: > > > On Feb 11, 2015 3:15 PM, "Jeremy Fitzhardinge" > 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 --------------080003000807090708020906 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 02/11/2015 03:28 PM, Linus Torvalds wrote:


On Feb 11, 2015 3:15 PM, "Jeremy Fitzhardinge" <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.

=C2=A0=C2=A0=C2=A0 J

--------------080003000807090708020906-- --===============8975782560207666258== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization --===============8975782560207666258==--