Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp833047pxu; Mon, 23 Nov 2020 05:27:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJx6fM6d52y7t7py8Qtvf/ryh9E+FPyjf9AtyaVm4zoZvvu09dRL8bb16FsE5mYz1Q8/F6ZZ X-Received: by 2002:a50:ed8d:: with SMTP id h13mr11413049edr.180.1606138031305; Mon, 23 Nov 2020 05:27:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606138031; cv=none; d=google.com; s=arc-20160816; b=kvKaAXQPNPFf5jpxZAc9i3OL57i9EnUW4Ax5sRViVWwEzYbfg7yna5GliLEb5UOPRr o9Zg2kWsAMd8C3NbLSXZn2PN9pvvaAz+JD3/lPP6ZVThqu4dimmJbkUOSWRoYF4oBzW3 Z4ZQqciHN/G+FP/611fmnmUdboicHs2wVvJCKGmvYVZrS07mFHFQ4Z6zx0Rv+BrQlXYa SmyeJWlVcgz/lqQ1xvuyFpQ9LZQ6dMIsC7HiLNAv2hadxcI4E/vXjg+po9suA/AOXmXY QlmxkXDcjNkBzwuHrnXs8IFR5uXv4CVlh+fsKf1hmsoIYu1UMnVtK3R/lRJ7QApUu6HJ NoqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=+sjQc7rb9wqrKqUL0Ks9DInbCJA4XPVX2NHVLuyEKN0=; b=xNSDgqhJ2h++T28EBxmjKxkwzsro5B05RWXn4N2oTG3TbFJKv6nU7/zXY/hCiS99z+ ku5aTkdgqoHr+bWJMrHBPH3TuUs6Tw7sFgnJWDXA1usBOciGB7f8j5Z2SPmW4LiRgSD2 USrFeXxzGHcvWY/M8XJX5TIiPP79bAmcLoU8UQP8TRKfP0XJRgm6Q58ealzmB8ImTmYP 0S3YGSdrJU3+d9088cHWxoSh5D8QsN+60jiG3VCfwTCOuMjo14vMTlUB/hX8KiSan1+X J4TcOYF9tZL7po7hlzqkyfCryi/AGe+DppVGnXMlgyP/R1+yEmmHqZt00G/3FLOZQ55c aWAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=ji3AqWcD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m16si6374814ejc.357.2020.11.23.05.26.48; Mon, 23 Nov 2020 05:27:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=ji3AqWcD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731560AbgKWNW7 (ORCPT + 99 others); Mon, 23 Nov 2020 08:22:59 -0500 Received: from mail.kernel.org ([198.145.29.99]:47482 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731552AbgKWMff (ORCPT ); Mon, 23 Nov 2020 07:35:35 -0500 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9655120857; Mon, 23 Nov 2020 12:35:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1606134934; bh=Y2sOZQ4sSsj0C7cifSzjThUwbEjiDrHl24AtaLf6C54=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ji3AqWcDQRK51cInlgou9BCBjdYjpfR/2NfeR3FxpcVcE2jilFSw1qDkRWje35QNG czvQUqglJPUye4Lf533n2r8LGVB8103wuCRIygcWQdQI/B4c6t9gXJ2QzX/JdxGiG2 uzBQrUEVoHx6u4zPcA0aZKzprAatZK5hjrRhE+S4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Arvind Sankar , Randy Dunlap , Andrew Morton , Nick Desaulniers , Kees Cook , Linus Torvalds , Sasha Levin Subject: [PATCH 5.4 044/158] compiler.h: fix barrier_data() on clang Date: Mon, 23 Nov 2020 13:21:12 +0100 Message-Id: <20201123121822.053682010@linuxfoundation.org> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20201123121819.943135899@linuxfoundation.org> References: <20201123121819.943135899@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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