lkml.org 
[lkml]   [2019]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectAbout compiler memory barrier for atomic_set/atomic_read on x86
Date
Hi Peter,
There is one question regarding following commit:

commit 69d927bba39517d0980462efc051875b7f4db185
Author: Peter Zijlstra <peterz@infradead.org>
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.

Regards
Yin, Fengwei

\
 
 \ /
  Last update: 2019-09-03 15:24    [W:0.034 / U:0.956 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site