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 X-Spam-Level: X-Spam-Status: No, score=-14.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1FD8CA9ECF for ; Fri, 1 Nov 2019 12:52:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4C45F208E3 for ; Fri, 1 Nov 2019 12:52:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="p7GnOvu+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C45F208E3 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A5B8F6B0005; Fri, 1 Nov 2019 08:52:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A0C9C6B0006; Fri, 1 Nov 2019 08:52:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 922C16B0007; Fri, 1 Nov 2019 08:52:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id 722AC6B0005 for ; Fri, 1 Nov 2019 08:52:30 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id C8A29180AD820 for ; Fri, 1 Nov 2019 12:52:29 +0000 (UTC) X-FDA: 76107697218.22.color63_6d07d2d0fc50d X-HE-Tag: color63_6d07d2d0fc50d X-Filterd-Recvd-Size: 7154 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Fri, 1 Nov 2019 12:52:29 +0000 (UTC) Received: by mail-wm1-f65.google.com with SMTP id c22so8984374wmd.1 for ; Fri, 01 Nov 2019 05:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=S0snpqGPjldXMZMvNjf0gnhgsKNaP2Jc2SmJ0XAOLsE=; b=p7GnOvu+IeteyBZ+QKYy8DID1LsNg6fryp+X+B5DvtfF9XsUAhr08kEsabLQrFol+U c1dcMNE5vh5JS5nuvt6856WubbmrYazTwcqngBXWuOmUpqntWy8lAg9yUZ9Q8rMh5T+L TP2OGy62PpMKmEmGnqke4pBeavdVD5bejKBPX3SNMc4u5nsGmR2RdTi3r62Uj+r8owXX L/2s7WZw+Vs7cWFmrhK0FFeOz8jGlOr6eA4WXBBoqj2GmLkzqcw3ZQnRMxgjy5brAUeV J0kVnxuUbvLPQTmTC/DIjMpOTGi1UeVmC6WB8U3YFd+Cbp2wG7jf3Ta3HnuolEGvZ69L K0cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=S0snpqGPjldXMZMvNjf0gnhgsKNaP2Jc2SmJ0XAOLsE=; b=leovWrMNb0Bz4UhhsZxF4DA1ERBxXNB60sSG8Tx7zx0zbXyx1h+4awgBz56K4ouGlC 0q956k5riBZfmGhHYGaF84lJmAaCtpYx2fBioxPFNd44rdPHY27pi7hFjp34MvZo05Fo UQUvZK+2COR3UH2qaEa+KnjzVwXmfQoprQuv68WaNmrTObuU2fw6+UxDf+qSGO4nKwNx YVukOZ0NaneAQlSKqElRc6y8DXrbpw8QMd0u9NF6IeWci9IUcjBBC3DXOWk4ddKt8wJM 7c7lJqLwzq6QiH0MmZNa9Qg/eESSgdk9LQOqoV63QvF4ljIVqWPvZOkcAv+EU6QJdHkv MUnw== X-Gm-Message-State: APjAAAUFj37Bum4RvFlAd03HxnnebdregtD//7dE5lZTu5q5LMFFrKC8 6/KN2tdauJI8u9yqY7z23gbKQPB/RCnKIhwW3EqRUg== X-Google-Smtp-Source: APXvYqwqc01FcGYqpTfh0H7IheRxYbD2P1BwfwLU+/njncjMMoPmLbmT1ettMj/12sWpQ8gZQNk67+zwLodZm/ESUOM= X-Received: by 2002:a1c:1f03:: with SMTP id f3mr10046698wmf.131.1572612747437; Fri, 01 Nov 2019 05:52:27 -0700 (PDT) MIME-Version: 1.0 References: <20191030142237.249532-1-glider@google.com> <20191030142237.249532-8-glider@google.com> In-Reply-To: From: Alexander Potapenko Date: Fri, 1 Nov 2019 13:52:16 +0100 Message-ID: Subject: Re: [PATCH RFC v2 07/25] kmsan: introduce __no_sanitize_memory and __SANITIZE_MEMORY__ To: Andrey Konovalov Cc: Vegard Nossum , Dmitry Vyukov , Linux Memory Management List , Alexander Viro , Andrew Morton , Andrey Ryabinin , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Christoph Hellwig , Dmitry Torokhov , Eric Dumazet , Eric Van Hensbergen , Greg Kroah-Hartman , Harry Wentland , Herbert Xu , Ingo Molnar , Jens Axboe , "Martin K. Petersen" , Martin Schwidefsky , "Michael S . Tsirkin" , Michal Simek , Petr Mladek , Sergey Senozhatsky , Steven Rostedt , Takashi Iwai , "Theodore Ts'o" , Thomas Gleixner , Wolfram Sang , Vasily Gorbik , Ilya Leoshkevich , Mark Rutland , Matthew Wilcox , Randy Dunlap , Marco Elver Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Wed, Oct 30, 2019 at 4:50 PM Andrey Konovalov wr= ote: > > On Wed, Oct 30, 2019 at 3:23 PM wrote: > > > > __no_sanitize_memory is a function attribute that makes KMSAN > > ignore the uninitialized values coming from the function's > > inputs, and initialize the function's outputs. > > > > Functions marked with this attribute can't be inlined into functions > > not marked with it, and vice versa. > > > > __SANITIZE_MEMORY__ is a macro that's defined iff the file is > > instrumented with KMSAN. This is not the same as CONFIG_KMSAN, which is > > defined for every file. > > > > Signed-off-by: Alexander Potapenko > > To: Alexander Potapenko > > Cc: Vegard Nossum > > Cc: Dmitry Vyukov > > Cc: linux-mm@kvack.org > > > > --- > > > > Change-Id: I1f1672652c8392f15f7ca8ac26cd4e71f9cc1e4b > > --- > > include/linux/compiler-clang.h | 8 ++++++++ > > include/linux/compiler-gcc.h | 5 +++++ > > 2 files changed, 13 insertions(+) > > > > diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-cl= ang.h > > index 333a6695a918..edba13a069a6 100644 > > --- a/include/linux/compiler-clang.h > > +++ b/include/linux/compiler-clang.h > > @@ -24,6 +24,14 @@ > > #define __no_sanitize_address > > #endif > > > > +/* KMSAN is a Clang-only tool, thus putting the defines here */ > > +#if __has_feature(memory_sanitizer) > > +# define __SANITIZE_MEMORY__ > > +# define __no_sanitize_memory __attribute__((no_sanitize("kernel-memor= y"))) > > For KASAN with Clang we ended up choosing to use > no_sanitize("address") instead of no_sanitize("kernel-address") to > make it match what GCC uses. Do we want to use no_sanitize("memory") > here? Since GCC doesn't currently implement KMSAN instrumentation, I think we can stick to the current annotation and let GCC catch up :) > > +#else > > +# define __no_sanitize_memory > > +#endif > > + > > /* > > * Not all versions of clang implement the the type-generic versions > > * of the builtin overflow checkers. Fortunately, clang implements > > diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.= h > > index d7ee4c6bad48..e5ebc788dde4 100644 > > --- a/include/linux/compiler-gcc.h > > +++ b/include/linux/compiler-gcc.h > > @@ -145,6 +145,11 @@ > > #define __no_sanitize_address > > #endif > > > > +/* > > + * GCC doesn't support KMSAN. > > + */ > > +#define __no_sanitize_memory > > + > > #if GCC_VERSION >=3D 50100 > > #define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1 > > #endif > > -- > > 2.24.0.rc0.303.g954a862665-goog > > --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg