Re: About compiler memory barrier for atomic_set/atomic_read on x86

[Peter Zijlstra]

On Tue, Sep 03, 2019 at 09:23:41PM +0800, Yin, Fengwei wrote:
> Hi Peter,
> There is one question regarding following commit:
> 
> commit 69d927bba39517d0980462efc051875b7f4db185
> Author: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Date:   Wed Apr 24 13:38:23 2019 +0200
> 
>     x86/atomic: Fix smp_mb__{before,after}_atomic()
> 
>     Recent probing at the Linux Kernel Memory Model uncovered a
>     'surprise'. Strongly ordered architectures where the atomic RmW
>     primitive implies full memory ordering and
>     smp_mb__{before,after}_atomic() are a simple barrier() (such as x86)
> 
> This change made atomic RmW operations include compiler barrier. And made
> __smp_mb__before_atomic/__smp_mb__after_atomic not include compiler
> barrier any more for x86.
> 
> We face the issue to handle atomic_set/atomic_read which is mapped to
> WRITE_ONCE/READ_ONCE on x86. These two functions don't include compiler
> barrier actually (if operator size is less than 8 bytes).
> 
> Before the commit 69d927bba39517d0980462efc051875b7f4db185, we could use
> __smp_mb__before_atomic/__smp_mb__after_atomic together with these two
> functions to make sure the memory order. It can't work after the commit
> 69d927bba39517d0980462efc051875b7f4db185. I am wandering whether
> we should make atomic_set/atomic_read also include compiler memory
> barrier on x86? Thanks.

No; using smp_mb__{before,after}_atomic() with atomic_{set,read}() is
_wrong_! And it is documented as such; see Documentation/atomic_t.txt.