Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3690906pxj; Tue, 1 Jun 2021 10:55:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxrOf8JQRqvodvQrfjFNfnbzvSa58gwW8jDJpS6mXLyKFNX5OCECnxIisH7MKcVlUFkLwe8 X-Received: by 2002:a17:906:e10d:: with SMTP id gj13mr13279393ejb.150.1622570112769; Tue, 01 Jun 2021 10:55:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622570112; cv=none; d=google.com; s=arc-20160816; b=TBIeBglMNUNU2dp9gt9Mey26k53d64cQkys7daTIHSUfX0XVEH0K0gWKqLvYzyGAzX b3hP/+NT0X2h6/Xp4ipFgzdz+cCJtag3OiGfz285eQ2Fv3pLTzTYv7PpcFTWIshavXU3 CVoOdOad4A08WuAEQaM0pRA+PZdFPNqq0ZVbD4yXw0MjbmijNpJKiLt4r1/RCjhhSUZC Aso21xuPLY42NXOtjRdc4xVi8fXhpHddKGG8NydHmhdDWgtMd1fE7r1JFPi9sKp/ZMZ9 qoliE2D6AxSzdoFKV5GE1+Mb8AaRaRPDqKADFnhFuWubl4t846bNpmTiYTpXRfcJLgRX cLMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=IKgq4o1KMFQWb4eqWEtxAreJyLSizVw7xMXtspskoP8=; b=dfEQY9pnUfXba11D7s+4luclcOikADAJgGrIyXFjYcBhjf80E5w9F/huqQiEul3dGu gQ992lLVUOX2OeZZOIVe1gMS42ykvDL+hkvIgrt8OCFBoIu+l79qk6Jwi2Pg50CXeVW1 3hZssm+Vm0dF2XWPJOx7m2prvgyOojLi02Cs+EiwWVrBp3EDEs70umXCit9TPOW9cY+4 d27DFsgHbhi+tokjnH1v5O/1RMieE0eyJgZx0dqqXlmeaE0PORA5zu0L4WjuzQrckMcR RL2ixdW2NBkMy2IUEeLdiV024PpvM0HfXpIvEDBzk7XKuOr4Gw8MOI2QNy0ESlYbUUXe Y3nQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=lqW4OyYI; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u21si3828297eds.89.2021.06.01.10.54.48; Tue, 01 Jun 2021 10:55:12 -0700 (PDT) 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=@google.com header.s=20161025 header.b=lqW4OyYI; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234631AbhFARzU (ORCPT + 99 others); Tue, 1 Jun 2021 13:55:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45040 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231918AbhFARzT (ORCPT ); Tue, 1 Jun 2021 13:55:19 -0400 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B7C16C061574 for ; Tue, 1 Jun 2021 10:53:37 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id i9so23103176lfe.13 for ; Tue, 01 Jun 2021 10:53:37 -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; bh=IKgq4o1KMFQWb4eqWEtxAreJyLSizVw7xMXtspskoP8=; b=lqW4OyYIyzQXiwKeWaV8Uk5Ch9HMdYdXO8sP+yS4DK+fiyA/TxN2TNwChsDB+cAUuR gz1+832czC+X1Eve6jIVmvAxrmJiDBBEjCSQdpQF3XjLzH9wqFZe/dgiNEiHsvg45h7/ FWYhKk1rd4gqtMglXo+9b1f54dAw7x9QTqK0Raav47QddGYKRabmE56cHdM3cUXCs1X5 +BgqBq6gkuImhEmxVwEk85VxFdwFWPLXNFTcQelD1PluCX+d5Ev2tgoEo8jpxxp+Kapc +nzXVW/181RyBw2hskDYeJzdiq/Lx6my/wjw4I7Ewlj50YhmUzAF60NsYWbkA3RPsT30 iYpw== 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; bh=IKgq4o1KMFQWb4eqWEtxAreJyLSizVw7xMXtspskoP8=; b=Gkq6Ak+uiQ1J+m4dv669TAGQox6Q6pffEu4jKZgC0eHym0Futqkz2E+95uXRSPVACh FU3e01h/J204yxLl1+dzRf1L5K2sa0OwN/TzJZvTuX0H9pzkR3pvaEvMzPW0EQYgBPJT T2gR7wFH4PLQWmCurwpzB+xZXJoFMmduIY/35iSIwNDNY0Tfl4n9l7Yzar506ZlrfRIw 2xfXral7PjzhF9jzqg/vBfddSSh0GX2DczZ1+uTOMZJzNyJXLvPdov++tzcSyQ09nW0U w6vQoRQOvJiY0yFJcg+cOur/Ey609H4UGbTNnSOExJ9nFmTJLvq7d2Up8xSf6wcLGF7d 73cg== X-Gm-Message-State: AOAM530k6oa5vVRZoWe9tZT5qSqHRpHNdxD+ZtTaPe+hX9M4XEHlqKJw 2HQuP/RY4j9um60lYDf+D+zA2p6/n0V/HZaxyMGTIA== X-Received: by 2002:a05:6512:46c:: with SMTP id x12mr5528836lfd.203.1622570015793; Tue, 01 Jun 2021 10:53:35 -0700 (PDT) MIME-Version: 1.0 References: <20210527162655.3246381-1-elver@google.com> In-Reply-To: From: Marco Elver Date: Tue, 1 Jun 2021 19:53:24 +0200 Message-ID: Subject: Re: [PATCH v2] kcov: add __no_sanitize_coverage to fix noinstr for all architectures To: Nick Desaulniers Cc: Andrew Morton , LKML , Nathan Chancellor , Miguel Ojeda , Peter Zijlstra , Kees Cook , Arvind Sankar , Will Deacon , Luc Van Oostenryck , Masahiro Yamada , Borislav Petkov , Sami Tolvanen , Arnd Bergmann , clang-built-linux , Dmitry Vyukov , Mark Rutland , kasan-dev Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 1 Jun 2021 at 19:46, Marco Elver wrote: > > On Tue, 1 Jun 2021 at 19:42, Nick Desaulniers wrote: > > On Thu, May 27, 2021 at 9:27 AM Marco Elver wrote: > > > > > > Until now no compiler supported an attribute to disable coverage > > > instrumentation as used by KCOV. > > > > > > To work around this limitation on x86, noinstr functions have their > > > coverage instrumentation turned into nops by objtool. However, this > > > solution doesn't scale automatically to other architectures, such as > > > arm64, which are migrating to use the generic entry code. > > > > > > Clang [1] and GCC [2] have added support for the attribute recently. > > > [1] https://github.com/llvm/llvm-project/commit/280333021e9550d80f5c1152a34e33e81df1e178 > > > [2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=cec4d4a6782c9bd8d071839c50a239c49caca689 > > > The changes will appear in Clang 13 and GCC 12. > > > > > > Add __no_sanitize_coverage for both compilers, and add it to noinstr. > > > > > > Note: In the Clang case, __has_feature(coverage_sanitizer) is only true > > > if the feature is enabled, and therefore we do not require an additional > > > defined(CONFIG_KCOV) (like in the GCC case where __has_attribute(..) is > > > always true) to avoid adding redundant attributes to functions if KCOV > > > is off. That being said, compilers that support the attribute will not > > > generate errors/warnings if the attribute is redundantly used; however, > > > where possible let's avoid it as it reduces preprocessed code size and > > > associated compile-time overheads. > > > > > > Signed-off-by: Marco Elver > > > Acked-by: Peter Zijlstra (Intel) > > > --- > > > v2: > > > * Implement __has_feature(coverage_sanitizer) in Clang > > > (https://reviews.llvm.org/D103159) and use instead of version check. > > > * Add Peter's Ack. > > > --- > > > include/linux/compiler-clang.h | 11 +++++++++++ > > > include/linux/compiler-gcc.h | 6 ++++++ > > > include/linux/compiler_types.h | 2 +- > > > 3 files changed, 18 insertions(+), 1 deletion(-) > > > > > > diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h > > > index adbe76b203e2..e15eebfa8e5d 100644 > > > --- a/include/linux/compiler-clang.h > > > +++ b/include/linux/compiler-clang.h > > > @@ -45,6 +45,17 @@ > > > #define __no_sanitize_undefined > > > #endif > > > > > > +/* > > > + * Support for __has_feature(coverage_sanitizer) was added in Clang 13 together > > > + * with no_sanitize("coverage"). Prior versions of Clang support coverage > > > + * instrumentation, but cannot be queried for support by the preprocessor. > > > > I'm not against a version check for supporting older releases (in > > addition to the cleaner feature check, since the feature check was > > non-existent); we can clean it up someday when clang-13 is the > > minimally supported version. Would having an additional version check > > help support existing/older releases here? > > The feature check will just return 0 on older releases, since the > feature does not exist there. Therefore, no additional code is > required to support older releases and a version check would be > redundant. And to avoid further confusion: -fsanitize-coverage exists, but the feature "coverage_sanitizer" queryable by __has_feature() does not exist. The confusion is the price we pay for this technical debt -- but I'd rather not write an essay about this in the comments. Most of it is in the commit message, and if people are still confused I hope they find this thread. There was also a v3 explaining this more in the comments, too: https://lkml.kernel.org/r/20210527194448.3470080-1-elver@google.com Hopefully that is all enough. > > > + */ > > > +#if __has_feature(coverage_sanitizer) > > > +#define __no_sanitize_coverage __attribute__((no_sanitize("coverage"))) > > > +#else > > > +#define __no_sanitize_coverage > > > +#endif > > > + > > Thanks, > -- Marco