From: Sasha Levin Date: Sun, 22 Nov 2020 19:20:08 +0000 (-0500) Subject: Fixes for 5.4 X-Git-Tag: v4.4.246~37 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=b7b1abe4d4eb3b98d85993f8f707969cf6c7c36c;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.4 Signed-off-by: Sasha Levin --- diff --git a/queue-5.4/compiler.h-fix-barrier_data-on-clang.patch b/queue-5.4/compiler.h-fix-barrier_data-on-clang.patch new file mode 100644 index 00000000000..80e3a6136d5 --- /dev/null +++ b/queue-5.4/compiler.h-fix-barrier_data-on-clang.patch @@ -0,0 +1,124 @@ +From b2a15cebf1822ff1ce0e390d45202f2231047ee2 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 13 Nov 2020 22:51:59 -0800 +Subject: compiler.h: fix barrier_data() on clang + +From: Arvind Sankar + +[ Upstream commit 3347acc6fcd4ee71ad18a9ff9d9dac176b517329 ] + +Commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h +mutually exclusive") neglected to copy barrier_data() from +compiler-gcc.h into compiler-clang.h. + +The definition in compiler-gcc.h was really to work around clang's more +aggressive optimization, so this broke barrier_data() on clang, and +consequently memzero_explicit() as well. + +For example, this results in at least the memzero_explicit() call in +lib/crypto/sha256.c:sha256_transform() being optimized away by clang. + +Fix this by moving the definition of barrier_data() into compiler.h. + +Also move the gcc/clang definition of barrier() into compiler.h, +__memory_barrier() is icc-specific (and barrier() is already defined +using it in compiler-intel.h) and doesn't belong in compiler.h. + +[rdunlap@infradead.org: fix ALPHA builds when SMP is not enabled] + +Link: https://lkml.kernel.org/r/20201101231835.4589-1-rdunlap@infradead.org +Fixes: 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive") +Signed-off-by: Arvind Sankar +Signed-off-by: Randy Dunlap +Signed-off-by: Andrew Morton +Tested-by: Nick Desaulniers +Reviewed-by: Nick Desaulniers +Reviewed-by: Kees Cook +Cc: +Link: https://lkml.kernel.org/r/20201014212631.207844-1-nivedita@alum.mit.edu +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + include/linux/compiler-clang.h | 5 ----- + include/linux/compiler-gcc.h | 19 ------------------- + include/linux/compiler.h | 18 ++++++++++++++++-- + 3 files changed, 16 insertions(+), 26 deletions(-) + +diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h +index 333a6695a918c..9b89141604ed0 100644 +--- a/include/linux/compiler-clang.h ++++ b/include/linux/compiler-clang.h +@@ -37,8 +37,3 @@ + #define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1 + #endif + +-/* The following are for compatibility with GCC, from compiler-gcc.h, +- * and may be redefined here because they should not be shared with other +- * compilers, like ICC. +- */ +-#define barrier() __asm__ __volatile__("" : : : "memory") +diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h +index e8579412ad214..d8fab3ecf5120 100644 +--- a/include/linux/compiler-gcc.h ++++ b/include/linux/compiler-gcc.h +@@ -14,25 +14,6 @@ + # error Sorry, your compiler is too old - please upgrade it. + #endif + +-/* Optimization barrier */ +- +-/* The "volatile" is due to gcc bugs */ +-#define barrier() __asm__ __volatile__("": : :"memory") +-/* +- * This version is i.e. to prevent dead stores elimination on @ptr +- * where gcc and llvm may behave differently when otherwise using +- * normal barrier(): while gcc behavior gets along with a normal +- * barrier(), llvm needs an explicit input variable to be assumed +- * clobbered. The issue is as follows: while the inline asm might +- * access any memory it wants, the compiler could have fit all of +- * @ptr into memory registers instead, and since @ptr never escaped +- * from that, it proved that the inline asm wasn't touching any of +- * it. This version works well with both compilers, i.e. we're telling +- * the compiler that the inline asm absolutely may see the contents +- * of @ptr. See also: https://llvm.org/bugs/show_bug.cgi?id=15495 +- */ +-#define barrier_data(ptr) __asm__ __volatile__("": :"r"(ptr) :"memory") +- + /* + * This macro obfuscates arithmetic on a variable address so that gcc + * shouldn't recognize the original var, and make assumptions about it. +diff --git a/include/linux/compiler.h b/include/linux/compiler.h +index 448c91bf543b7..f164a9b12813f 100644 +--- a/include/linux/compiler.h ++++ b/include/linux/compiler.h +@@ -80,11 +80,25 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val, + + /* Optimization barrier */ + #ifndef barrier +-# define barrier() __memory_barrier() ++/* The "volatile" is due to gcc bugs */ ++# define barrier() __asm__ __volatile__("": : :"memory") + #endif + + #ifndef barrier_data +-# define barrier_data(ptr) barrier() ++/* ++ * This version is i.e. to prevent dead stores elimination on @ptr ++ * where gcc and llvm may behave differently when otherwise using ++ * normal barrier(): while gcc behavior gets along with a normal ++ * barrier(), llvm needs an explicit input variable to be assumed ++ * clobbered. The issue is as follows: while the inline asm might ++ * access any memory it wants, the compiler could have fit all of ++ * @ptr into memory registers instead, and since @ptr never escaped ++ * from that, it proved that the inline asm wasn't touching any of ++ * it. This version works well with both compilers, i.e. we're telling ++ * the compiler that the inline asm absolutely may see the contents ++ * of @ptr. See also: https://llvm.org/bugs/show_bug.cgi?id=15495 ++ */ ++# define barrier_data(ptr) __asm__ __volatile__("": :"r"(ptr) :"memory") + #endif + + /* workaround for GCC PR82365 if needed */ +-- +2.27.0 + diff --git a/queue-5.4/series b/queue-5.4/series index 1060cec71af..4720d76fbe1 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -41,3 +41,4 @@ arm64-smp-tell-rcu-about-cpus-that-fail-to-come-onli.patch vfs-remove-lockdep-bogosity-in-__sb_start_write.patch gfs2-fix-possible-reference-leak-in-gfs2_check_blk_t.patch hwmon-pwm-fan-fix-rpm-calculation.patch +compiler.h-fix-barrier_data-on-clang.patch