--- /dev/null
+From fe8c8a126806fea4465c43d62a1f9d273a572bf5 Mon Sep 17 00:00:00 2001
+From: Cesar Eduardo Barros <cesarb@cesarb.eti.br>
+Date: Mon, 25 Nov 2013 22:00:41 -0200
+Subject: crypto: more robust crypto_memneq
+
+From: Cesar Eduardo Barros <cesarb@cesarb.eti.br>
+
+commit fe8c8a126806fea4465c43d62a1f9d273a572bf5 upstream.
+
+[Only use the compiler.h portion of this patch, to get the
+OPTIMIZER_HIDE_VAR() macro, which we need for other -stable patches
+- gregkh]
+
+Disabling compiler optimizations can be fragile, since a new
+optimization could be added to -O0 or -Os that breaks the assumptions
+the code is making.
+
+Instead of disabling compiler optimizations, use a dummy inline assembly
+(based on RELOC_HIDE) to block the problematic kinds of optimization,
+while still allowing other optimizations to be applied to the code.
+
+The dummy inline assembly is added after every OR, and has the
+accumulator variable as its input and output. The compiler is forced to
+assume that the dummy inline assembly could both depend on the
+accumulator variable and change the accumulator variable, so it is
+forced to compute the value correctly before the inline assembly, and
+cannot assume anything about its value after the inline assembly.
+
+This change should be enough to make crypto_memneq work correctly (with
+data-independent timing) even if it is inlined at its call sites. That
+can be done later in a followup patch.
+
+Compile-tested on x86_64.
+
+Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.eti.br>
+Acked-by: Daniel Borkmann <dborkman@redhat.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/compiler-gcc.h | 3 +++
+ include/linux/compiler-intel.h | 7 +++++++
+ include/linux/compiler.h | 4 ++++
+ 3 files changed, 14 insertions(+)
+
+--- a/include/linux/compiler-gcc.h
++++ b/include/linux/compiler-gcc.h
+@@ -37,6 +37,9 @@
+ __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
+ (typeof(ptr)) (__ptr + (off)); })
+
++/* Make the optimizer believe the variable can be manipulated arbitrarily. */
++#define OPTIMIZER_HIDE_VAR(var) __asm__ ("" : "=r" (var) : "0" (var))
++
+ #ifdef __CHECKER__
+ #define __must_be_array(arr) 0
+ #else
+--- a/include/linux/compiler-intel.h
++++ b/include/linux/compiler-intel.h
+@@ -15,6 +15,7 @@
+ */
+ #undef barrier
+ #undef RELOC_HIDE
++#undef OPTIMIZER_HIDE_VAR
+
+ #define barrier() __memory_barrier()
+
+@@ -23,6 +24,12 @@
+ __ptr = (unsigned long) (ptr); \
+ (typeof(ptr)) (__ptr + (off)); })
+
++/* This should act as an optimization barrier on var.
++ * Given that this compiler does not have inline assembly, a compiler barrier
++ * is the best we can do.
++ */
++#define OPTIMIZER_HIDE_VAR(var) barrier()
++
+ /* Intel ECC compiler doesn't support __builtin_types_compatible_p() */
+ #define __must_be_array(a) 0
+
+--- a/include/linux/compiler.h
++++ b/include/linux/compiler.h
+@@ -170,6 +170,10 @@ void ftrace_likely_update(struct ftrace_
+ (typeof(ptr)) (__ptr + (off)); })
+ #endif
+
++#ifndef OPTIMIZER_HIDE_VAR
++#define OPTIMIZER_HIDE_VAR(var) barrier()
++#endif
++
+ /* Not-quite-unique ID. */
+ #ifndef __UNIQUE_ID
+ # define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __LINE__)