search for: single_

...th "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. > > 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(). Uh, so, READ/WRITE_ONCE are non-atomic now. I missed that. If READ/WRITE_ONCE are non...

...th "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. > > 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(). Uh, so, READ/WRITE_ONCE are non-atomic now. I missed that. If READ/WRITE_ONCE are non...

...hem. 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(). >

...hem. 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(). >

On Fri, Nov 25, 2016 at 04:21:39PM +0100, Dmitry Vyukov wrote: > > READ/WRITE_ONCE imply atomicity. Even if their names don't spell it (a > function name doesn't have to spell all of its guarantees). Most of > the uses of READ/WRITE_ONCE will be broken if they are not atomic. In practice, this is certainly the assumption made by many/most users of the *_ONCE() accessors.

...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. 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().

...s with 64bit PTEs. Some for > others (I think sparc). And the mm/ code is perfectly fine with these > PTE accesses being done NOT atomic. In that case do we even need _ONCE at all? Are there assumptions these are two 32 bit reads? > > > > > 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(). > >

On Fri, Nov 25, 2016 at 3:56 PM, Boqun Feng <boqun.feng at gmail.com> wrote: > On Fri, Nov 25, 2016 at 01:44:04PM +0100, Peter Zijlstra wrote: >> On Fri, Nov 25, 2016 at 01:40:44PM +0100, Peter Zijlstra wrote: >> > #define SINGLE_LOAD(x) \ >> > {( \ >> > compiletime_assert_atomic_type(typeof(x)); \ >> >> Should be: >> >> compiletime_assert_atomic_type(x); >&...

On Fri, Nov 25, 2016 at 3:56 PM, Boqun Feng <boqun.feng at gmail.com> wrote: > On Fri, Nov 25, 2016 at 01:44:04PM +0100, Peter Zijlstra wrote: >> On Fri, Nov 25, 2016 at 01:40:44PM +0100, Peter Zijlstra wrote: >> > #define SINGLE_LOAD(x) \ >> > {( \ >> > compiletime_assert_atomic_type(typeof(x)); \ >> >> Should be: >> >> compiletime_assert_atomic_type(x); >&...