[<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