Re: [PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()
From: Christian Borntraeger <hidden>
Date: 2016-11-25 16:50:22
Also in:
kvm, lkml, netdev
Possibly related (same subject, not in this thread)
- 2016-11-25 · Re: [PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE() · Linus Torvalds <torvalds@linux-foundation.org>
- 2016-11-25 · Re: [PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE() · Christian Borntraeger <hidden>
- 2016-11-25 · Re: [PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE() · Mark Rutland <mark.rutland@arm.com>
- 2016-11-25 · Re: [PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE() · Linus Torvalds <torvalds@linux-foundation.org>
- 2016-11-25 · Re: [PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE() · Mark Rutland <mark.rutland@arm.com>
On 11/25/2016 05:17 PM, Peter Zijlstra wrote:
On Fri, Nov 25, 2016 at 04:10:04PM +0000, Mark Rutland wrote:quoted
On Fri, Nov 25, 2016 at 04:21:39PM +0100, Dmitry Vyukov wrote:quoted
quoted
What are use cases for such primitive that won't be OK with "read once _and_ atomically"?I have none to hand.Whatever triggers the __builtin_memcpy() paths, and even the size==8 paths on 32bit. You could put a WARN in there to easily find them.
There were several cases that I found during writing the *ONCE stuff. For example there are some 32bit ppc variants with 64bit PTEs. Some for others (I think sparc). And the mm/ code is perfectly fine with these PTE accesses being done NOT atomic.
The advantage of introducing the SINGLE_{LOAD,STORE}() helpers is that
they compiletime validate this the size is 'right' and can runtime check
alignment constraints.
IE, they are strictly stronger than {READ,WRITE}_ONCE().