similar to: [PATCH 00/13] Finish off [smp_]read_barrier_depends()

Hi all, This is version three of the patches I previously posted here: v1: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ v2: https://lore.kernel.org/r/20200630173734.14057-1-will at kernel.org Changes since v2 include: * Actually add the barrier in READ_ONCE() for Alpha! * Implement Alpha's smp_load_acquire() using __READ_ONCE(), rather than the other

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The

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 +

Hi all, In an attempt to remove the remaining traces of [smp_]read_barrier_depends() following my previous patches to strengthen READ_ONCE() for Alpha [1], I ended up trying to decipher the read_barrier_depends() usage in the vhost driver: --->8 // drivers/vhost/vhost.c static int get_indirect(struct vhost_virtqueue *vq, struct iovec iov[], unsigned int iov_size, unsigned int *out_num,

Hi all, In an attempt to remove the remaining traces of [smp_]read_barrier_depends() following my previous patches to strengthen READ_ONCE() for Alpha [1], I ended up trying to decipher the read_barrier_depends() usage in the vhost driver: --->8 // drivers/vhost/vhost.c static int get_indirect(struct vhost_virtqueue *vq, struct iovec iov[], unsigned int iov_size, unsigned int *out_num,

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:

On 01/14/2016 04:04 AM, Will Deacon wrote: > Consequently, it's important that the architecture back-ends implement > these portable primitives (e.g. smp_mb()) in a way that satisfies the > kernel memory model so that core code doesn't need to worry about the > underlying architecture for synchronisation purposes. It seems you don't listen me. I said multiple times -

On 01/14/2016 04:04 AM, Will Deacon wrote: > Consequently, it's important that the architecture back-ends implement > these portable primitives (e.g. smp_mb()) in a way that satisfies the > kernel memory model so that core code doesn't need to worry about the > underlying architecture for synchronisation purposes. It seems you don't listen me. I said multiple times -

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

Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote: > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > The reason for this is that smp_read_barrier_depends() must order the > pointer load against any subsequent read or write through a dereference > of that pointer. For

Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote: > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > The reason for this is that smp_read_barrier_depends() must order the > pointer load against any subsequent read or write through a dereference > of that pointer. For

Changes since v2: - extended checkpatch tests for barriers, and added patches teaching it to warn about incorrect usage of barriers (__smp_xxx barriers are for use by asm-generic code only), should help prevent misuse by arch code to address comments by Russell King - patched more instances of xen to use virt_ barriers as suggested by Stefano Stabellini - implemented a 2 byte xchg on sh

Changes since v2: - extended checkpatch tests for barriers, and added patches teaching it to warn about incorrect usage of barriers (__smp_xxx barriers are for use by asm-generic code only), should help prevent misuse by arch code to address comments by Russell King - patched more instances of xen to use virt_ barriers as suggested by Stefano Stabellini - implemented a 2 byte xchg on sh

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the

Hi Paul, On Mon, Jan 18, 2016 at 07:46:29AM -0800, Paul E. McKenney wrote: > On Mon, Jan 18, 2016 at 04:19:29PM +0800, Herbert Xu wrote: > > Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote: > > > > > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > > > smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. >

Hi Paul, On Mon, Jan 18, 2016 at 07:46:29AM -0800, Paul E. McKenney wrote: > On Mon, Jan 18, 2016 at 04:19:29PM +0800, Herbert Xu wrote: > > Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote: > > > > > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > > > smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. >

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't