[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] x86 spinlock: Fix memory corruption on completing completions
- To: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
- From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
- Date: Wed, 11 Feb 2015 23:08:03 -0800
- Cc: Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx>, KVM list <kvm@xxxxxxxxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Jason Wang <jasowang@xxxxxxxxxx>, Oleg Nesterov <oleg@xxxxxxxxxx>, Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>, Peter Anvin <hpa@xxxxxxxxx>, Andi Kleen <ak@xxxxxxxxxxxxxxx>, Andrey Ryabinin <a.ryabinin@xxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Christian Borntraeger <borntraeger@xxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Paul McKenney <paulmck@xxxxxxxxxxxxxxxxxx>, Davidlohr Bueso <dave@xxxxxxxxxxxx>, Sasha Levin <sasha.levin@xxxxxxxxxx>, Dave Jones <davej@xxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, virtualization <virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx>, Waiman Long <waiman.long@xxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Paolo Bonzini <pbonzini@xxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Thu, 12 Feb 2015 07:08:23 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
On 02/11/2015 03:28 PM, Linus Torvalds
wrote:
On Feb 11, 2015 3:15 PM, "Jeremy Fitzhardinge" <jeremy@xxxxxxxx>
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
|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
