From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: [PATCH v3 02/19] compiler.h: Split {READ, WRITE}_ONCE definitions out into rwonce.h Date: Mon, 20 Jul 2020 16:55:02 +0100 Message-ID: <20200720155501.GA12064@willie-the-truck> References: <20200710165203.31284-1-will@kernel.org> <20200710165203.31284-3-will@kernel.org> <20200713122322.GD72639@debian-boqun.qqnc3lrjykvubdpftowmye0fmh.lx.internal.cloudapp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595260508; bh=CPfkp2QBSP3gKifkBSkUyRSWEi+JHbUnJ+ZB0izj7DY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=a5D8vvsdPtuyNYv8qE1jt1t3R9hwgKBR8Ede9nALJ4GZh3UC88Nws0YRzwzNNeorI I6F07W869uTS3luWta0bx2aHQA6vGJ8h5e5sxVfXxpGZN+kyk/pEq36G0rCjq/iKmZ /FYTeONkLgSEhZ5hG4MefWUaAVfzMFvXZKz/EBg0= Content-Disposition: inline In-Reply-To: <20200713122322.GD72639@debian-boqun.qqnc3lrjykvubdpftowmye0fmh.lx.internal.cloudapp.net> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" To: boqun.feng@gmail.com Cc: Joel Fernandes , Mark Rutland , Marco Elver , Kees Cook , "Paul E. McKenney" , "Michael S. Tsirkin" , Peter Zijlstra , Catalin Marinas , Nick Desaulniers , linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, Ivan Kokshaysky , linux-arm-kernel@lists.infradead.org, Sami Tolvanen , linux-alpha@vger.kernel.org, Alan Stern , Matt Turner , kernel-team@android.com, Arnd Bergmann , Richard Henderson On Mon, Jul 13, 2020 at 08:23:22PM +0800, boqun.feng@gmail.com wrote: > On Fri, Jul 10, 2020 at 05:51:46PM +0100, Will Deacon wrote: > > diff --git a/include/asm-generic/rwonce.h b/include/asm-generic/rwonce.h > > new file mode 100644 > > index 000000000000..92cc2f223cb3 > > --- /dev/null > > +++ b/include/asm-generic/rwonce.h > > @@ -0,0 +1,91 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > + * Prevent the compiler from merging or refetching reads or writes. The > > + * compiler is also forbidden from reordering successive instances of > > + * READ_ONCE and WRITE_ONCE, but only when the compiler is aware of some > > + * particular ordering. One way to make the compiler aware of ordering is to > > + * put the two invocations of READ_ONCE or WRITE_ONCE in different C > > + * statements. > > + * > > + * These two macros will also work on aggregate data types like structs or > > + * unions. > > + * > > + * Their two major use cases are: (1) Mediating communication between > > + * process-level code and irq/NMI handlers, all running on the same CPU, > > + * and (2) Ensuring that the compiler does not fold, spindle, or otherwise > > + * mutilate accesses that either do not require ordering or that interact > > + * with an explicit memory barrier or atomic instruction that provides the > > + * required ordering. > > + */ > > +#ifndef __ASM_GENERIC_RWONCE_H > > +#define __ASM_GENERIC_RWONCE_H > > + > > +#ifndef __ASSEMBLY__ > > + > > +#include > > +#include > > +#include > > + > > +#include > > + > > +/* > > + * Use __READ_ONCE() instead of READ_ONCE() if you do not require any > > + * atomicity or dependency ordering guarantees. Note that this may result > > + * in tears! > > + */ > > +#define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x)) > > + > > +#define __READ_ONCE_SCALAR(x) \ > > +({ \ > > + __unqual_scalar_typeof(x) __x = __READ_ONCE(x); \ > > + smp_read_barrier_depends(); \ > > + (typeof(x))__x; \ > > +}) > > + > > +#define READ_ONCE(x) \ > > +({ \ > > + compiletime_assert_rwonce_type(x); \ > > Does it make sense if we also move the definition of this compile time > assertion into rwonce.h too? Yes, that looks straightforward enough. Thanks for the suggestion! I'll also try to get this lot into -next this week. Will