search for: _once

On Fri, Nov 8, 2019 at 6:01 PM Will Deacon <will at kernel.org> wrote: > > In preparation for allowing architectures to define their own > implementation of the 'READ_ONCE()' macro, move the generic > '{READ,WRITE}_ONCE()' definitions out of the unwieldy 'linux/compiler.h' > and into a new 'rwonce.h' header under 'asm-generic'. Adding Christian Borntr?ger to Cc, he originally added the READ_ONCE()/WRITE_ONCE() code. I wonde...

On Fri, Nov 8, 2019 at 6:01 PM Will Deacon <will at kernel.org> wrote: > > In preparation for allowing architectures to define their own > implementation of the 'READ_ONCE()' macro, move the generic > '{READ,WRITE}_ONCE()' definitions out of the unwieldy 'linux/compiler.h' > and into a new 'rwonce.h' header under 'asm-generic'. Adding Christian Borntr?ger to Cc, he originally added the READ_ONCE()/WRITE_ONCE() code. I wonde...

On Tue, Jun 30, 2020 at 7:37 PM Will Deacon <will at kernel.org> wrote: > > In preparation for allowing architectures to define their own > implementation of the READ_ONCE() macro, move the generic > {READ,WRITE}_ONCE() definitions out of the unwieldy 'linux/compiler.h' > file and into a new 'rwonce.h' header under 'asm-generic'. > > Acked-by: Paul E. McKenney <paulmck at kernel.org> > Signed-off-by: Will Deacon <will a...

For several reasons, it would be beneficial to kill off ACCESS_ONCE() tree-wide, in favour of {READ,WRITE}_ONCE(). These work with aggregate types, more obviously document their intended behaviour, and are necessary for tools like KTSAN to work correctly (as otherwise reads and writes cannot be instrumented separately). While it's possible to script the bulk o...

For several reasons, it would be beneficial to kill off ACCESS_ONCE() tree-wide, in favour of {READ,WRITE}_ONCE(). These work with aggregate types, more obviously document their intended behaviour, and are necessary for tools like KTSAN to work correctly (as otherwise reads and writes cannot be instrumented separately). While it's possible to script the bulk o...

...traeger at de.ibm.com> wrote: > On 08.11.19 20:57, Arnd Bergmann wrote: > > On Fri, Nov 8, 2019 at 6:01 PM Will Deacon <will at kernel.org> wrote: > >> > >> In preparation for allowing architectures to define their own > >> implementation of the 'READ_ONCE()' macro, move the generic > >> '{READ,WRITE}_ONCE()' definitions out of the unwieldy 'linux/compiler.h' > >> and into a new 'rwonce.h' header under 'asm-generic'. > > > > Adding Christian Borntr?ger to Cc, he originally added the &g...

On Thu, 24 Nov 2016 10:25:14 +0000 Mark Rutland <mark.rutland at arm.com> wrote: > As a step towards killing off ACCESS_ONCE, use {READ,WRITE}_ONCE() for the > virtio tools uaccess primitives, pulling these in from <linux/compiler.h>. > > With this done, we can kill off the now-unused ACCESS_ONCE() definition. > > Signed-off-by: Mark Rutland <mark.rutland at arm.com> > Cc: Jason Wang <j...

On 2016?11?24? 18:25, Mark Rutland wrote: > As a step towards killing off ACCESS_ONCE, use {READ,WRITE}_ONCE() for the > virtio tools uaccess primitives, pulling these in from <linux/compiler.h>. > > With this done, we can kill off the now-unused ACCESS_ONCE() definition. > > Signed-off-by: Mark Rutland <mark.rutland at arm.com> > Cc: Jason Wang <jas...

On 08.11.19 20:57, Arnd Bergmann wrote: > On Fri, Nov 8, 2019 at 6:01 PM Will Deacon <will at kernel.org> wrote: >> >> In preparation for allowing architectures to define their own >> implementation of the 'READ_ONCE()' macro, move the generic >> '{READ,WRITE}_ONCE()' definitions out of the unwieldy 'linux/compiler.h' >> and into a new 'rwonce.h' header under 'asm-generic'. > > Adding Christian Borntr?ger to Cc, he originally added the > READ_ONCE()/WRIT...

Hi Arnd, On Tue, Jun 30, 2020 at 09:11:32PM +0200, Arnd Bergmann wrote: > On Tue, Jun 30, 2020 at 7:37 PM Will Deacon <will at kernel.org> wrote: > > > > In preparation for allowing architectures to define their own > > implementation of the READ_ONCE() macro, move the generic > > {READ,WRITE}_ONCE() definitions out of the unwieldy 'linux/compiler.h' > > file and into a new 'rwonce.h' header under 'asm-generic'. > > > > Acked-by: Paul E. McKenney <paulmck at kernel.org> > > Signed-off-b...

As a step towards killing off ACCESS_ONCE, use {READ,WRITE}_ONCE() for the virtio tools uaccess primitives, pulling these in from <linux/compiler.h>. With this done, we can kill off the now-unused ACCESS_ONCE() definition. Signed-off-by: Mark Rutland <mark.rutland at arm.com> Cc: Jason Wang <jasowang at redhat.com> Cc:...

On Thu, Nov 24, 2016 at 10:36:58PM +0200, Michael S. Tsirkin wrote: > On Thu, Nov 24, 2016 at 10:25:11AM +0000, Mark Rutland wrote: > > For several reasons, it would be beneficial to kill off ACCESS_ONCE() > > tree-wide, in favour of {READ,WRITE}_ONCE(). These work with aggregate types, > > more obviously document their intended behaviour, and are necessary for tools > > like KTSAN to work correctly (as otherwise reads and writes cannot be > > instrumented separately). >...

On Thu, Nov 24, 2016 at 10:36:58PM +0200, Michael S. Tsirkin wrote: > On Thu, Nov 24, 2016 at 10:25:11AM +0000, Mark Rutland wrote: > > For several reasons, it would be beneficial to kill off ACCESS_ONCE() > > tree-wide, in favour of {READ,WRITE}_ONCE(). These work with aggregate types, > > more obviously document their intended behaviour, and are necessary for tools > > like KTSAN to work correctly (as otherwise reads and writes cannot be > > instrumented separately). >...

On Fri, Jul 10, 2020 at 05:51:46PM +0100, Will Deacon wrote: > In preparation for allowing architectures to define their own > implementation of the READ_ONCE() macro, move the generic > {READ,WRITE}_ONCE() definitions out of the unwieldy 'linux/compiler.h' > file and into a new 'rwonce.h' header under 'asm-generic'. > > Acked-by: Paul E. McKenney <paulmck at kernel.org> > Signed-off-by: Will Deacon <will...

In preparation for allowing architectures to define their own implementation of the READ_ONCE() macro, move the generic {READ,WRITE}_ONCE() definitions out of the unwieldy 'linux/compiler.h' file and into a new 'rwonce.h' header under 'asm-generic'. Acked-by: Paul E. McKenney <paulmck at kernel.org> Signed-off-by: Will Deacon <will at kernel.org> --- in...

In preparation for allowing architectures to define their own implementation of the READ_ONCE() macro, move the generic {READ,WRITE}_ONCE() definitions out of the unwieldy 'linux/compiler.h' file and into a new 'rwonce.h' header under 'asm-generic'. Acked-by: Paul E. McKenney <paulmck at kernel.org> Signed-off-by: Will Deacon <will at kernel.org> --- in...

On Thu, Nov 24, 2016 at 10:25:11AM +0000, Mark Rutland wrote: > For several reasons, it would be beneficial to kill off ACCESS_ONCE() > tree-wide, in favour of {READ,WRITE}_ONCE(). These work with aggregate types, > more obviously document their intended behaviour, and are necessary for tools > like KTSAN to work correctly (as otherwise reads and writes cannot be > instrumented separately). > > While it's...

In preparation for allowing architectures to define their own implementation of the 'READ_ONCE()' macro, move the generic '{READ,WRITE}_ONCE()' definitions out of the unwieldy 'linux/compiler.h' and into a new 'rwonce.h' header under 'asm-generic'. Signed-off-by: Will Deacon <will at kernel.org> --- include/asm-generic/Kbuild | 1 + incl...

...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-atomic, half of kernel is broken. All these loads of flags, ringbuffer positions, pointers, etc are broken. What about restoring READ/WRITE_ONCE as atomic, and introducing separate primitives for _non_ atom...

...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-atomic, half of kernel is broken. All these loads of flags, ringbuffer positions, pointers, etc are broken. What about restoring READ/WRITE_ONCE as atomic, and introducing separate primitives for _non_ atom...