Subject: Re: [PATCH 3.12 05/98] kernel: Provide READ_ONCE and ASSIGN_ONCE
To: Jiri Slaby <jslaby@suse.cz>, stable@vger.kernel.org
References: <def91dea48a3acb14c2379b9461ae659d95616a2.1460380917.git.jslaby@suse.cz>
 <b5be8baf9e0d5ea035588a0430b2af4989e07572.1460380917.git.jslaby@suse.cz>
Cc: linux-kernel@vger.kernel.org
From: Christian Borntraeger <borntraeger@de.ibm.com>
Message-ID: <570BB102.1010001@de.ibm.com>
Date: Mon, 11 Apr 2016 16:13:22 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <b5be8baf9e0d5ea035588a0430b2af4989e07572.1460380917.git.jslaby@suse.cz>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4449
Lines: 117

On 04/11/2016 03:22 PM, Jiri Slaby wrote:
> From: Christian Borntraeger <borntraeger@de.ibm.com>
> 
> 3.12-stable review patch.  If anyone has any objections, please let me know.
> 

As I wrote you 2 weeks ago, there are several patches on top, which are necessary to not
break compile on some architectures or to get the final names.
Please do not apply this stand-alone.
 

> ===============
> 
> commit 230fa253df6352af12ad0a16128760b5cb3f92df upstream.
> 
> ACCESS_ONCE does not work reliably on non-scalar types. For
> example gcc 4.6 and 4.7 might remove the volatile tag for such
> accesses during the SRA (scalar replacement of aggregates) step
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145)
> 
> Let's provide READ_ONCE/ASSIGN_ONCE that will do all accesses via
> scalar types as suggested by Linus Torvalds. Accesses larger than
> the machines word size cannot be guaranteed to be atomic. These
> macros will use memcpy and emit a build warning.
> 
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> ---
>  include/linux/compiler.h | 74 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 74 insertions(+)
> 
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 19a199414bd0..237063adbe1b 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -179,6 +179,80 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
>  # define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __LINE__)
>  #endif
> 
> +#include <uapi/linux/types.h>
> +
> +static __always_inline void data_access_exceeds_word_size(void)
> +#ifdef __compiletime_warning
> +__compiletime_warning("data access exceeds word size and won't be atomic")
> +#endif
> +;
> +
> +static __always_inline void data_access_exceeds_word_size(void)
> +{
> +}
> +
> +static __always_inline void __read_once_size(volatile void *p, void *res, int size)
> +{
> +	switch (size) {
> +	case 1: *(__u8 *)res = *(volatile __u8 *)p; break;
> +	case 2: *(__u16 *)res = *(volatile __u16 *)p; break;
> +	case 4: *(__u32 *)res = *(volatile __u32 *)p; break;
> +#ifdef CONFIG_64BIT
> +	case 8: *(__u64 *)res = *(volatile __u64 *)p; break;
> +#endif
> +	default:
> +		barrier();
> +		__builtin_memcpy((void *)res, (const void *)p, size);
> +		data_access_exceeds_word_size();
> +		barrier();
> +	}
> +}
> +
> +static __always_inline void __assign_once_size(volatile void *p, void *res, int size)
> +{
> +	switch (size) {
> +	case 1: *(volatile __u8 *)p = *(__u8 *)res; break;
> +	case 2: *(volatile __u16 *)p = *(__u16 *)res; break;
> +	case 4: *(volatile __u32 *)p = *(__u32 *)res; break;
> +#ifdef CONFIG_64BIT
> +	case 8: *(volatile __u64 *)p = *(__u64 *)res; break;
> +#endif
> +	default:
> +		barrier();
> +		__builtin_memcpy((void *)p, (const void *)res, size);
> +		data_access_exceeds_word_size();
> +		barrier();
> +	}
> +}
> +
> +/*
> + * Prevent the compiler from merging or refetching reads or writes. The
> + * compiler is also forbidden from reordering successive instances of
> + * READ_ONCE, ASSIGN_ONCE and ACCESS_ONCE (see below), 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,
> + * ASSIGN_ONCE or ACCESS_ONCE() in different C statements.
> + *
> + * In contrast to ACCESS_ONCE these two macros will also work on aggregate
> + * data types like structs or unions. If the size of the accessed data
> + * type exceeds the word size of the machine (e.g., 32 bits or 64 bits)
> + * READ_ONCE() and ASSIGN_ONCE()  will fall back to memcpy and print a
> + * compile-time warning.
> + *
> + * 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.
> + */
> +
> +#define READ_ONCE(x) \
> +	({ typeof(x) __val; __read_once_size(&x, &__val, sizeof(__val)); __val; })
> +
> +#define ASSIGN_ONCE(val, x) \
> +	({ typeof(x) __val; __val = val; __assign_once_size(&x, &__val, sizeof(__val)); __val; })
> +
>  #endif /* __KERNEL__ */
> 
>  #endif /* __ASSEMBLY__ */
>