On Fri, 15 May 2020 at 17:04, Marco Elver <[email protected]> wrote:
>
> The volatile access no longer needs to be wrapped in data_race(),
> because we require compilers that emit instrumentation distinguishing
> volatile accesses.
>
> Signed-off-by: Marco Elver <[email protected]>
> ---
>  include/linux/compiler.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 17c98b215572..fce56402c082 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -229,7 +229,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, 
> int val,
>  #define __READ_ONCE_SCALAR(x)                                          \
>  ({                                                                     \
>         typeof(x) *__xp = &(x);                                         \
> -       __unqual_scalar_typeof(x) __x = data_race(__READ_ONCE(*__xp));  \
> +       __unqual_scalar_typeof(x) __x = __READ_ONCE(*__xp);             \
>         kcsan_check_atomic_read(__xp, sizeof(*__xp));                   \

Some self-review: We don't need kcsan_check_atomic anymore, and this
should be removed.

I'll send v2 to address this (together with fix to data_race()
removing nested statement expressions).

>         smp_read_barrier_depends();                                     \
>         (typeof(x))__x;                                                 \
> @@ -250,7 +250,7 @@ do {                                                      
>                   \
>  do {                                                                   \
>         typeof(x) *__xp = &(x);                                         \
>         kcsan_check_atomic_write(__xp, sizeof(*__xp));                  \

Same.

> -       data_race(({ __WRITE_ONCE(*__xp, val); 0; }));                  \
> +       __WRITE_ONCE(*__xp, val);                                       \
>  } while (0)
>
>  #define WRITE_ONCE(x, val)                                             \
> --
> 2.26.2.761.g0e0b3e54be-goog
>

Reply via email to