[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a2dBFiu37_YAvpoug-+RkKqq3i+8-Tkv5HPBag3JAEJrA@mail.gmail.com>
Date:   Fri, 10 Jan 2020 20:42:37 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Will Deacon <will@...nel.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Android Kernel Team <kernel-team@...roid.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Peter Zijlstra <peterz@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Segher Boessenkool <segher@...nel.crashing.org>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        Luc Van Oostenryck <luc.vanoostenryck@...il.com>
Subject: Re: [RFC PATCH 7/8] locking/barriers: Use '__unqual_scalar_typeof'
 for load-acquire macros
On Fri, Jan 10, 2020 at 5:57 PM Will Deacon <will@...nel.org> wrote:
> @@ -128,10 +128,10 @@ do {                                                                      \
>  #ifndef __smp_load_acquire
>  #define __smp_load_acquire(p)                                          \
>  ({                                                                     \
> -       typeof(*p) ___p1 = READ_ONCE(*p);                               \
> +       __unqual_scalar_typeof(*p) ___p1 = READ_ONCE(*p);               \
>         compiletime_assert_atomic_type(*p);                             \
>         __smp_mb();                                                     \
> -       ___p1;                                                          \
> +       (typeof(*p))___p1;                                              \
>  })
Doesn't that last  (typeof(*p))___p1 mean you put the potential
'volatile' back on the assignment after you went through the
effort of taking it out?
       Arnd
Powered by blists - more mailing lists
 
