[PATCH v2] compiler-intel: fix wrong compiler barrier() macro

[Daniel Borkmann]

Cleanup commit 73679e508201 ("compiler-intel.h: Remove duplicate
definition") removed the double definition of __memory_barrier()
intrinsics.

However, in doing so, it also removed the preceding #undef barrier
by accident, meaning, the actual barrier() macro from compiler-gcc.h
with inline asm is still in place as __GNUC__ is provided.

Subsequently, barrier() can never be defined as __memory_barrier()
from compiler.h since it already has a definition in place and if
we trust the comment in compiler-intel.h, ecc doesn't support gcc
specific asm statements.

I don't have an ecc at hand, so a revert of that cleanup would be
the safest option, imho, as it has been like this since pre git
times.

Fixes: 73679e508201 ("compiler-intel.h: Remove duplicate definition")
Signed-off-by: Daniel Borkmann <daniel@xxxxxxxxxxxxx>
Reviewed-by: Pranith Kumar <bobby.prani@xxxxxxxxx>
Cc: Pranith Kumar <bobby.prani@xxxxxxxxx>
Cc: H. Peter Anvin <hpa@xxxxxxxxxxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxxxxx>
Cc: mancha security <mancha1@xxxxxxxx>
---
 v1->v2:
  - fixed the wrong commit hash in 1st occurence of commit msg
  - rest as is, also kept Pranith's Reviewed-by tag

 include/linux/compiler-intel.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/compiler-intel.h b/include/linux/compiler-intel.h
index ba147a1..5529c52 100644
--- a/include/linux/compiler-intel.h
+++ b/include/linux/compiler-intel.h
@@ -13,9 +13,12 @@
 /* Intel ECC compiler doesn't support gcc specific asm stmts.
  * It uses intrinsics to do the equivalent things.
  */
+#undef barrier
 #undef RELOC_HIDE
 #undef OPTIMIZER_HIDE_VAR
 
+#define barrier() __memory_barrier()
+
 #define RELOC_HIDE(ptr, off)					\
   ({ unsigned long __ptr;					\
      __ptr = (unsigned long) (ptr);				\
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/