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=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 87074C433ED for ; Wed, 19 May 2021 11:57:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 62CD1611AE for ; Wed, 19 May 2021 11:57:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241721AbhESL6W (ORCPT ); Wed, 19 May 2021 07:58:22 -0400 Received: from foss.arm.com ([217.140.110.172]:34714 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237480AbhESL6U (ORCPT ); Wed, 19 May 2021 07:58:20 -0400 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 90DC9101E; Wed, 19 May 2021 04:57:00 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.30.170]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 44C933F719; Wed, 19 May 2021 04:56:57 -0700 (PDT) Date: Wed, 19 May 2021 12:56:54 +0100 From: Mark Rutland To: Marco Elver Cc: Peter Zijlstra , Nick Desaulniers , Josh Poimboeuf , Will Deacon , "Jose E. Marchesi" , "Paul E. McKenney" , Ard Biesheuvel , Catalin Marinas , linux-toolchains@vger.kernel.org Subject: Re: Linux Plumbers Conf 2021 Message-ID: <20210519115654.GC2797@C02TD0UTHF1T.local> References: <20210518121447.GB7914@willie-the-truck> <20210518124311.r4fwv6lfz3erkqnb@treble> <20210518124819.lkzzgjcrh4cc5a6i@treble> <20210518200306.GE21560@worktop.programming.kicks-ass.net> <20210519093240.GA2797@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Wed, May 19, 2021 at 12:19:38PM +0200, Marco Elver wrote: > On Wed, 19 May 2021 at 11:32, Mark Rutland wrote: > > > > On Tue, May 18, 2021 at 10:03:06PM +0200, Peter Zijlstra wrote: > > > On Tue, May 18, 2021 at 09:57:26AM -0700, Nick Desaulniers wrote: > > > > On Tue, May 18, 2021 at 6:23 AM Peter Zijlstra wrote: > > > > > > > > - validates noinstr annotation; *HOWEVER* we rely on objtool to NOP > > > > > all __sanitizer_cov_* calls in .noinstr/.entry text sections because > > > > > __no_sanitize_cov is 'broken' in all known compilers. > > > > > > > > ^ Do you have more information on this? > > > > > > Random link in the middle of a relevant thread: > > > > > > https://lkml.kernel.org/r/CANpmjNPNa2f=kAF6c199oYVJ0iSyirQRGxeOBLxa9PmakSXRbA@mail.gmail.com > > > > > > Notable quote: > > > > > > "It's everywhere. We cannot mark noinstr functions to not be > > > instrumented by KCOV/-fsanitize-coverage, because no compiler provides > > > an attribute to do so. GCC doesn't have > > > __attribute__((no_sanitize_coverage)) and Clang doesn't have > > > __attribute__((no_sanitize("coverage")), and therefore we can't have > > > __no_sanitize_coverage." > > Hmm, we really need to add those. I looked at it briefly for Clang, > and I think it turned out more complicated than I thought and then > after seeing objtool "solved it", more pressing things came up. :-/ > > > Yuck; I wasn't aware of that. > > > > This means that arm64's entry code is unsound (along with some other > > parts) if kcov is enabled. > > We still have "KCOV_INSTRUMENT_file.o := n" (or "KCOV_INSTRUMENT := n" > for everything in a Makefile) for now. Not great, but for entry code > it might be good enough. FWIW, I've prepared some patches to do just that; it requires moving some functions around so that we don't unnecessarily prevent instrumentation, but otherwise that does seem to be good enough for what we have today. I'll send that out shortly as part of some entry code rework. > > That *really* needs an attribute, and going forward we shouldn't accept > > new compiler instrumentation that we can't opt-out of like this. > > Strangely enough, in Clang, there's -fsanitize-coverage-blocklist, but > that's pretty useless for the kernel. Maintaining a list of functions > doesn't scale, and we just need an attribute. I'll ping a few of the > people who know Clang's fsanitize-coverage a bit better. Great, thanks! I think that kernel-side we should have a policy going forward that for new instrumentation it must be possible to opt-out like this (and when support is added, `noinstr` gets upsated to opt-out). Correspondingly on the compiler-side, it'd be good if that was seen as a general requirement for new instrumentation. Thanks, Mark.