From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 893B3C433F5 for ; Wed, 15 Dec 2021 13:24:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E8C4B6B0071; Wed, 15 Dec 2021 08:24:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E15526B0073; Wed, 15 Dec 2021 08:24:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C8E516B0074; Wed, 15 Dec 2021 08:24:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0223.hostedemail.com [216.40.44.223]) by kanga.kvack.org (Postfix) with ESMTP id B61D56B0071 for ; Wed, 15 Dec 2021 08:24:24 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 5D869181AEF09 for ; Wed, 15 Dec 2021 13:24:14 +0000 (UTC) X-FDA: 78920097228.08.FEF36D4 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf05.hostedemail.com (Postfix) with ESMTP id D89D5100010 for ; Wed, 15 Dec 2021 13:24:13 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B4E75D6E; Wed, 15 Dec 2021 05:24:12 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.67.176]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 007803F774; Wed, 15 Dec 2021 05:24:07 -0800 (PST) Date: Wed, 15 Dec 2021 13:24:04 +0000 From: Mark Rutland To: Alexander Potapenko , Marco Elver , Peter Zijlstra Cc: Alexander Viro , Andrew Morton , Andrey Konovalov , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Borislav Petkov , Christoph Hellwig , Christoph Lameter , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Herbert Xu , Ilya Leoshkevich , Ingo Molnar , Jens Axboe , Joonsoo Kim , Kees Cook , Matthew Wilcox , "Michael S. Tsirkin" , Pekka Enberg , Petr Mladek , Steven Rostedt , Thomas Gleixner , Vasily Gorbik , Vegard Nossum , Vlastimil Babka , linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 07/43] compiler_attributes.h: add __disable_sanitizer_instrumentation Message-ID: References: <20211214162050.660953-1-glider@google.com> <20211214162050.660953-8-glider@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211214162050.660953-8-glider@google.com> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: D89D5100010 X-Stat-Signature: mzm7xew8ft1y8mxnhttunw3rt1h8oh9e Authentication-Results: imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of mark.rutland@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=mark.rutland@arm.com; dmarc=pass (policy=none) header.from=arm.com X-HE-Tag: 1639574653-987229 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Dec 14, 2021 at 05:20:14PM +0100, Alexander Potapenko wrote: > The new attribute maps to > __attribute__((disable_sanitizer_instrumentation)), which will be > supported by Clang >= 14.0. Future support in GCC is also possible. > > This attribute disables compiler instrumentation for kernel sanitizer > tools, making it easier to implement noinstr. It is different from the > existing __no_sanitize* attributes, which may still allow certain types > of instrumentation to prevent false positives. When you say the __no_sanitize* attributes allow some instrumentation, does that apply to any of the existing KASAN/KCSAN/KCOV support, or just for KMSAN? The documentation just says the same as the commit message: | This is not the same as __attribute__((no_sanitize(...))), which depending on | the tool may still insert instrumentation to prevent false positive reports. ... which implies the other instrumentation might not be suprressed. I ask because architectures which select ARCH_WANTS_NO_INSTR *need* to be able to suppress all instrumentation. It's fine if that means they need a new version of clang for KMSAN, but if there's latent instrumentation we have more bugs to fix first... Thanks, Mark. > Signed-off-by: Alexander Potapenko > --- > Link: https://linux-review.googlesource.com/id/Ic0123ce99b33ab7d5ed1ae90593425be8d3d774a > --- > include/linux/compiler_attributes.h | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h > index b9121afd87331..37e2600202216 100644 > --- a/include/linux/compiler_attributes.h > +++ b/include/linux/compiler_attributes.h > @@ -308,6 +308,24 @@ > # define __compiletime_warning(msg) > #endif > > +/* > + * Optional: only supported since clang >= 14.0 > + * > + * clang: https://clang.llvm.org/docs/AttributeReference.html#disable-sanitizer-instrumentation > + * > + * disable_sanitizer_instrumentation is not always similar to > + * no_sanitize(()): the latter may still let specific sanitizers > + * insert code into functions to prevent false positives. Unlike that, > + * disable_sanitizer_instrumentation prevents all kinds of instrumentation to > + * functions with the attribute. > + */ > +#if __has_attribute(disable_sanitizer_instrumentation) > +# define __disable_sanitizer_instrumentation \ > + __attribute__((disable_sanitizer_instrumentation)) > +#else > +# define __disable_sanitizer_instrumentation > +#endif > + > /* > * gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-weak-function-attribute > * gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-weak-variable-attribute > -- > 2.34.1.173.g76aa8bc2d0-goog >