search for: __smp_read_barrier_depends

...:"memory") > > #ifdef CONFIG_SMP > diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h > index 2cafdbb9ae4c..fa2e2ef72b68 100644 > --- a/include/asm-generic/barrier.h > +++ b/include/asm-generic/barrier.h > @@ -70,6 +70,24 @@ > #define __smp_read_barrier_depends() read_barrier_depends() > #endif > > +#if defined(COMPILER_HAS_OPTIMIZER_HIDE_VAR) && \ > + !defined(ARCH_NEEDS_READ_BARRIER_DEPENDS) > + > +#define dependent_ptr_mb(ptr, val) ({ \ > + long dependent_ptr_mb_val = (long)(val); \ > + long dependent_ptr_mb_p...

...:"memory") > > #ifdef CONFIG_SMP > diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h > index 2cafdbb9ae4c..fa2e2ef72b68 100644 > --- a/include/asm-generic/barrier.h > +++ b/include/asm-generic/barrier.h > @@ -70,6 +70,24 @@ > #define __smp_read_barrier_depends() read_barrier_depends() > #endif > > +#if defined(COMPILER_HAS_OPTIMIZER_HIDE_VAR) && \ > + !defined(ARCH_NEEDS_READ_BARRIER_DEPENDS) > + > +#define dependent_ptr_mb(ptr, val) ({ \ > + long dependent_ptr_mb_val = (long)(val); \ > + long dependent_ptr_mb_p...

...s() __asm__ __volatile__("mb": : :"memory") #ifdef CONFIG_SMP diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h index 2cafdbb9ae4c..fa2e2ef72b68 100644 --- a/include/asm-generic/barrier.h +++ b/include/asm-generic/barrier.h @@ -70,6 +70,24 @@ #define __smp_read_barrier_depends() read_barrier_depends() #endif +#if defined(COMPILER_HAS_OPTIMIZER_HIDE_VAR) && \ + !defined(ARCH_NEEDS_READ_BARRIER_DEPENDS) + +#define dependent_ptr_mb(ptr, val) ({ \ + long dependent_ptr_mb_val = (long)(val); \ + long dependent_ptr_mb_ptr = (long)(ptr) - dependent_ptr_mb_val; \...

So as explained in Documentation/memory-barriers.txt e.g. a load followed by a store require a full memory barrier, to avoid store being ordered before the load. Similarly load-load requires a read memory barrier. Thinking about it, we can actually create a data dependency by mixing the first loaded value into the pointer being accessed. This adds an API for this and uses it in virtio. Written

...gt; #ifdef CONFIG_SMP > > diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h > > index 2cafdbb9ae4c..fa2e2ef72b68 100644 > > --- a/include/asm-generic/barrier.h > > +++ b/include/asm-generic/barrier.h > > @@ -70,6 +70,24 @@ > > #define __smp_read_barrier_depends() read_barrier_depends() > > #endif > > +#if defined(COMPILER_HAS_OPTIMIZER_HIDE_VAR) && \ > > + !defined(ARCH_NEEDS_READ_BARRIER_DEPENDS) > > + > > +#define dependent_ptr_mb(ptr, val) ({ \ > > + long dependent_ptr_mb_val = (long)(val); \ > &gt...

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

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

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

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