similar to: [PATCH 00/18] Allow architectures to override __READ_ONCE()

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 all, Although [smp_]read_barrier_depends() became part of READ_ONCE() in commit 76ebbe78f739 ("locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE()"), it still limps on in the Linux memory model with the sinister hope of attracting innocent new users so that it becomes impossible to remove altogether. Let's strike before it's too late: there's only

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

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:

The patch below fixes the recent UML compilation failure in -rc5-mm1 without making the UML build reach further into the i386 headers. It splits the i386 ptrace.h and system.h into UML-usable and UML-unusable pieces. The string "abi" is in there because I did ptrace.h first, and that involves separating the ptrace ABI stuff from everything else (if pt_regs is not considered part of

The patch below fixes the recent UML compilation failure in -rc5-mm1 without making the UML build reach further into the i386 headers. It splits the i386 ptrace.h and system.h into UML-usable and UML-unusable pieces. The string "abi" is in there because I did ptrace.h first, and that involves separating the ptrace ABI stuff from everything else (if pt_regs is not considered part of

This changes the pv ops code generation to more closely match reality. For example, instead of: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) vmlinux will now show: pushfq pop %rax nop nop nop nop nop which is what the runtime version of the code will show in most cases. This idea was suggested by Andy Lutomirski. The benefits are: - For the most common runtime cases

This changes the pv ops code generation to more closely match reality. For example, instead of: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) vmlinux will now show: pushfq pop %rax nop nop nop nop nop which is what the runtime version of the code will show in most cases. This idea was suggested by Andy Lutomirski. The benefits are: - For the most common runtime cases

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> ---

On Fri, Jul 10, 2020 at 9:52 AM Will Deacon <will at kernel.org> wrote: > > Now that 'smp_read_barrier_depends()' has gone the way of the Norwegian > Blue, drop the inclusion of <asm/barrier.h> in 'asm-generic/rwonce.h'. > > This requires fixups to some architecture vdso headers which were > previously relying on 'asm/barrier.h' coming in via

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

When building with LTO, there is an increased risk of the compiler converting an address dependency headed by a READ_ONCE() invocation into a control dependency and consequently allowing for harmful reordering by the CPU. Ensure that such transformations are harmless by overriding the generic READ_ONCE() definition with one that provides acquire semantics when building with LTO. Signed-off-by:

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

Rather then relying on the core code to use smp_read_barrier_depends() as part of the READ_ONCE() definition, instead override __READ_ONCE() in the Alpha code so that it is treated the same way as smp_load_acquire(). Acked-by: Paul E. McKenney <paulmck at kernel.org> Signed-off-by: Will Deacon <will at kernel.org> --- arch/alpha/include/asm/barrier.h | 61

On Tue, Jun 30, 2020 at 06:37:20PM +0100, Will Deacon wrote: > Rather then relying on the core code to use smp_read_barrier_depends() > as part of the READ_ONCE() definition, instead override __READ_ONCE() > in the Alpha code so that it is treated the same way as > smp_load_acquire(). > > Acked-by: Paul E. McKenney <paulmck at kernel.org> > Signed-off-by: Will Deacon

On Tue, Jun 30, 2020 at 06:37:20PM +0100, Will Deacon wrote: > Rather then relying on the core code to use smp_read_barrier_depends() > as part of the READ_ONCE() definition, instead override __READ_ONCE() > in the Alpha code so that it is treated the same way as > smp_load_acquire(). > > Acked-by: Paul E. McKenney <paulmck at kernel.org> > Signed-off-by: Will Deacon