[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200521102214.GC5360@willie-the-truck>
Date: Thu, 21 May 2020 11:22:14 +0100
From: Will Deacon <will@...nel.org>
To: Marco Elver <elver@...gle.com>
Cc: "Paul E. McKenney" <paulmck@...nel.org>,
Dmitry Vyukov <dvyukov@...gle.com>,
Alexander Potapenko <glider@...gle.com>,
Andrey Konovalov <andreyknvl@...gle.com>,
kasan-dev <kasan-dev@...glegroups.com>,
LKML <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: [PATCH -tip 08/10] READ_ONCE, WRITE_ONCE: Remove data_race()
wrapping
On Thu, May 21, 2020 at 12:18:14PM +0200, Marco Elver wrote:
> On Thu, 21 May 2020 at 11:47, Marco Elver <elver@...gle.com> wrote:
> > On Fri, 15 May 2020 at 17:04, Marco Elver <elver@...gle.com> wrote:
> > > 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).
>
> The other thing here is that we no longer require __xp, and can just
> pass x into __READ_ONCE.
>
> > > 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.
>
> __xp can also be removed.
>
> Note that this effectively aliases __WRITE_ONCE_SCALAR to
> __WRITE_ONCE. To keep the API consistent with READ_ONCE, I assume we
> want to keep __WRITE_ONCE_SCALAR, in case it is meant to change in
> future?
Ha! So I think this ends up being very similar to what I had *before* I
rebased onto KCSAN:
https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/tree/include/linux/compiler.h?h=rwonce/cleanup#n202
in which case you can drop __WRITE_ONCE_SCALAR; the _SCALAR things shouldn't
be used outside of the implementation anyway.
Will
Powered by blists - more mailing lists