Message ID | 20231109155101.186028-1-paul.heidekrueger@tum.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b129:0:b0:403:3b70:6f57 with SMTP id q9csp530050vqs; Thu, 9 Nov 2023 07:58:01 -0800 (PST) X-Google-Smtp-Source: AGHT+IGMvqChJlWNdoJP2gceCt+DBA+17GftKNrZevIq06Pt8977C/uHaHZYv9PjCigvVDwkNmZZ X-Received: by 2002:a05:6a20:548a:b0:185:672f:525b with SMTP id i10-20020a056a20548a00b00185672f525bmr2203716pzk.6.1699545481066; Thu, 09 Nov 2023 07:58:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699545481; cv=none; d=google.com; s=arc-20160816; b=ZB+K8FwL4ygTuv+kQlIRrbY/VSuTYj8vk51MBRT3us7eOpR10enuA+nrfOVfAF5HH7 8Z3hdeOmh31ROgDWvbMgypTUnhetqh8mrm4E5cSHt/tI6hJgjZsA1Vv45RiCO8M+TwmO g30IPc/UJb/feW30jeVt304UeMg8pKGoXEg0UKlvNu3KiP3qtK35HJ+/K88UicdDzGX9 0PJ8z3D8U8ik9zOrM7UazbpQCuve1jDwySNv8A9gn4kdF39WmzfNDfty3dM4NSutXXQR 1tnKIVUg+hLFIkz6zUMk9Ax9mrLKhUCjSeWiPV2Uuifme/aKpxP/kkIMPjPt5paJJYdV xp/Q== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=gkUWT9gaMxgFhLHKiecgnCwkyltpAf99XujgPjq88yM=; fh=s83eWP35m7qf2ShTBn5oHosHNJ9J1JpOqAmcwAMYcpc=; b=GN2eO7zCFWjazSv8uV3QvPMlZGEp1H19xx3D7nMIDxvWTApU37qleGhtdiIxiDH+RQ qm2EkqftlzXbbHWR6H4wJFUz6qjWdRzCBptld7P8tufMRsF+XKWIlIVzRgWFfhV3lM0N mY6gyrRm5Z68j6Shlo4tcKmMR2Vss5KN7Eo/mKi96DXqFSDYbfyN2TQfSqDp+qYGm9ft Im0aZbynF2I/alA65S/x1OM/k3o5xYZGzXmOAB2yXR080tktd/qPV372DBXXk9upUMNk frK21onlutiDhwwAuJ8Ig32enKzH6bNibdsZaU4EFvXrTQKmYV7TDZro0I1KkPAdg4EJ mqFg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@tum.de header.s=tu-postout21 header.b="N/TXfWMy"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=tum.de Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id f12-20020a056a001acc00b006be31c8eea5si16644786pfv.61.2023.11.09.07.58.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Nov 2023 07:58:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@tum.de header.s=tu-postout21 header.b="N/TXfWMy"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=tum.de Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id AC4A68020706; Thu, 9 Nov 2023 07:57:58 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234424AbjKIP5r (ORCPT <rfc822;lhua1029@gmail.com> + 31 others); Thu, 9 Nov 2023 10:57:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53154 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229914AbjKIP5r (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 9 Nov 2023 10:57:47 -0500 X-Greylist: delayed 382 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Thu, 09 Nov 2023 07:57:44 PST Received: from postout2.mail.lrz.de (postout2.mail.lrz.de [129.187.255.138]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 035D02736 for <linux-kernel@vger.kernel.org>; Thu, 9 Nov 2023 07:57:43 -0800 (PST) Received: from lxmhs52.srv.lrz.de (localhost [127.0.0.1]) by postout2.mail.lrz.de (Postfix) with ESMTP id 4SR5z762ZDzyXQ; Thu, 9 Nov 2023 16:51:15 +0100 (CET) Authentication-Results: postout.lrz.de (amavisd-new); dkim=pass (2048-bit key) reason="pass (just generated, assumed good)" header.d=tum.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tum.de; h= content-transfer-encoding:content-type:content-type:mime-version :x-mailer:message-id:date:date:subject:subject:from:from :received:received; s=tu-postout21; t=1699545075; bh=FLhY3lTuUc3 WtyOcLcUxakIx8PVClCaL3IV9f8Y5L90=; b=N/TXfWMy9zpCCJLzYvbIxaD0dUx WELXUYSKYFnM4U7W/wj7sCYI8VkdTVh2oU//d9j2jKQcrMYMlRyeaENeujdkxQyI 77WlHKChdwbGgtuyusTPax/PEyn5SofxzwRiIwvPOFUJgaXwzmwGYsFboD5HbOxi YYIXff2pDJcunVzbDdRQS9a6Fl6ivPLkczplRnTJoj64uS8g3sT04BvbkaJzPPDM E5pvVfm7p29h0y0bf2r/JdEu9AHl5DoHP9nGbM+6Xrcz1AC6jMzKL6NSC0v4pl/P GMMu9mHNgfzZh4CT5OUM/pBrQVI7JyOkjoZ80MzOvWixtnFqRgC5EOzw6Yw== X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs52.srv.lrz.de X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 Received: from postout2.mail.lrz.de ([127.0.0.1]) by lxmhs52.srv.lrz.de (lxmhs52.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id JcuZfT6noPOB; Thu, 9 Nov 2023 16:51:15 +0100 (CET) Received: from sienna.cit.tum.de (Monitor.dos.cit.tum.de [131.159.38.165]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by postout2.mail.lrz.de (Postfix) with ESMTPSA id 4SR5z66SBszySZ; Thu, 9 Nov 2023 16:51:14 +0100 (CET) From: =?utf-8?q?Paul_Heidekr=C3=BCger?= <paul.heidekrueger@tum.de> To: Andrey Ryabinin <ryabinin.a.a@gmail.com>, Alexander Potapenko <glider@google.com>, Andrey Konovalov <andreyknvl@gmail.com>, Dmitry Vyukov <dvyukov@google.com>, Vincenzo Frascino <vincenzo.frascino@arm.com>, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org Cc: =?utf-8?q?Paul_Heidekr=C3=BCger?= <paul.heidekrueger@tum.de> Subject: [PATCH] kasan: default to inline instrumentation Date: Thu, 9 Nov 2023 15:51:00 +0000 Message-Id: <20231109155101.186028-1-paul.heidekrueger@tum.de> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Thu, 09 Nov 2023 07:57:58 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1782102602177134322 X-GMAIL-MSGID: 1782102602177134322 |
Series |
kasan: default to inline instrumentation
|
|
Commit Message
Paul Heidekrüger
Nov. 9, 2023, 3:51 p.m. UTC
KASan inline instrumentation can yield up to a 2x performance gain at
the cost of a larger binary.
Make inline instrumentation the default, as suggested in the bug report
below.
When an architecture does not support inline instrumentation, it should
set ARCH_DISABLE_KASAN_INLINE, as done by PowerPC, for instance.
CC: Dmitry Vyukov <dvyukov@google.com>
Reported-by: Andrey Konovalov <andreyknvl@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=203495
Signed-off-by: Paul Heidekrüger <paul.heidekrueger@tum.de>
---
lib/Kconfig.kasan | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Thu, Nov 9, 2023 at 4:51 PM Paul Heidekrüger <paul.heidekrueger@tum.de> wrote: > > KASan inline instrumentation can yield up to a 2x performance gain at > the cost of a larger binary. > > Make inline instrumentation the default, as suggested in the bug report > below. > > When an architecture does not support inline instrumentation, it should > set ARCH_DISABLE_KASAN_INLINE, as done by PowerPC, for instance. > > CC: Dmitry Vyukov <dvyukov@google.com> > Reported-by: Andrey Konovalov <andreyknvl@gmail.com> > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=203495 > Signed-off-by: Paul Heidekrüger <paul.heidekrueger@tum.de> > --- > lib/Kconfig.kasan | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan > index fdca89c05745..935eda08b1e1 100644 > --- a/lib/Kconfig.kasan > +++ b/lib/Kconfig.kasan > @@ -134,7 +134,7 @@ endchoice > choice > prompt "Instrumentation type" > depends on KASAN_GENERIC || KASAN_SW_TAGS > - default KASAN_OUTLINE > + default KASAN_INLINE if !ARCH_DISABLE_KASAN_INLINE > > config KASAN_OUTLINE > bool "Outline instrumentation" > -- > 2.40.1 > Acked-by: Andrey Konovalov <andreyknvl@gmail.com> Thank you for taking care of this!
On Thu, 9 Nov 2023 at 22:08, Andrey Konovalov <andreyknvl@gmail.com> wrote: > > On Thu, Nov 9, 2023 at 4:51 PM Paul Heidekrüger > <paul.heidekrueger@tum.de> wrote: > > > > KASan inline instrumentation can yield up to a 2x performance gain at > > the cost of a larger binary. > > > > Make inline instrumentation the default, as suggested in the bug report > > below. > > > > When an architecture does not support inline instrumentation, it should > > set ARCH_DISABLE_KASAN_INLINE, as done by PowerPC, for instance. > > > > CC: Dmitry Vyukov <dvyukov@google.com> > > Reported-by: Andrey Konovalov <andreyknvl@gmail.com> > > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=203495 > > Signed-off-by: Paul Heidekrüger <paul.heidekrueger@tum.de> > > --- > > lib/Kconfig.kasan | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan > > index fdca89c05745..935eda08b1e1 100644 > > --- a/lib/Kconfig.kasan > > +++ b/lib/Kconfig.kasan > > @@ -134,7 +134,7 @@ endchoice > > choice > > prompt "Instrumentation type" > > depends on KASAN_GENERIC || KASAN_SW_TAGS > > - default KASAN_OUTLINE > > + default KASAN_INLINE if !ARCH_DISABLE_KASAN_INLINE > > > > config KASAN_OUTLINE > > bool "Outline instrumentation" > > -- > > 2.40.1 > > > > Acked-by: Andrey Konovalov <andreyknvl@gmail.com> > > Thank you for taking care of this! Reviewed-by: Marco Elver <elver@google.com> +Cc Andrew (get_maintainers.pl doesn't add Andrew automatically for KASAN sources in lib/) Thanks, -- Marco
On Tue, 14 Nov 2023 12:00:49 +0100 Marco Elver <elver@google.com> wrote: > +Cc Andrew (get_maintainers.pl doesn't add Andrew automatically for > KASAN sources in lib/) Did I do this right? From: Andrew Morton <akpm@linux-foundation.org> Subject: MAINTAINERS: add Andrew Morton for lib/* Date: Tue Nov 14 03:02:04 PM PST 2023 Add myself as the fallthough maintainer for material under lib/ Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- MAINTAINERS | 7 +++++++ 1 file changed, 7 insertions(+) --- a/MAINTAINERS~a +++ a/MAINTAINERS @@ -12209,6 +12209,13 @@ F: include/linux/nd.h F: include/uapi/linux/ndctl.h F: tools/testing/nvdimm/ +LIBRARY CODE +M: Andrew Morton <akpm@linux-foundation.org> +L: linux-kernel@vger.kernel.org +S: Supported +T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-nonmm-unstable +F: lib/* + LICENSES and SPDX stuff M: Thomas Gleixner <tglx@linutronix.de> M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On Tue, 2023-11-14 at 15:11 -0800, Andrew Morton wrote: > On Tue, 14 Nov 2023 12:00:49 +0100 Marco Elver <elver@google.com> wrote: > > > +Cc Andrew (get_maintainers.pl doesn't add Andrew automatically for > > KASAN sources in lib/) > > Did I do this right? > > > From: Andrew Morton <akpm@linux-foundation.org> > Subject: MAINTAINERS: add Andrew Morton for lib/* > Date: Tue Nov 14 03:02:04 PM PST 2023 > > Add myself as the fallthough maintainer for material under lib/ > > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > --- > > MAINTAINERS | 7 +++++++ > 1 file changed, 7 insertions(+) > > --- a/MAINTAINERS~a > +++ a/MAINTAINERS > @@ -12209,6 +12209,13 @@ F: include/linux/nd.h > F: include/uapi/linux/ndctl.h > F: tools/testing/nvdimm/ > > +LIBRARY CODE > +M: Andrew Morton <akpm@linux-foundation.org> > +L: linux-kernel@vger.kernel.org > +S: Supported Dunno. There are a lot of already specifically maintained or supported files in lib/ Maybe be a reviewer?
On Wed, 15 Nov 2023 at 06:38, Joe Perches <joe@perches.com> wrote: > > On Tue, 2023-11-14 at 15:11 -0800, Andrew Morton wrote: > > On Tue, 14 Nov 2023 12:00:49 +0100 Marco Elver <elver@google.com> wrote: > > > > > +Cc Andrew (get_maintainers.pl doesn't add Andrew automatically for > > > KASAN sources in lib/) > > > > Did I do this right? If the signal to noise ratio is acceptable, something like that could be helpful. New contributors like Paul in this case may have an easier time, if none of the reviewers spot the missing Cc. However, folks familiar with subsystems that also have bits in lib/ (or elsewhere) know to Cc you. It worked in this case. Thanks, -- Marco > > From: Andrew Morton <akpm@linux-foundation.org> > > Subject: MAINTAINERS: add Andrew Morton for lib/* > > Date: Tue Nov 14 03:02:04 PM PST 2023 > > > > Add myself as the fallthough maintainer for material under lib/ > > > > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > > --- > > > > MAINTAINERS | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > --- a/MAINTAINERS~a > > +++ a/MAINTAINERS > > @@ -12209,6 +12209,13 @@ F: include/linux/nd.h > > F: include/uapi/linux/ndctl.h > > F: tools/testing/nvdimm/ > > > > +LIBRARY CODE > > +M: Andrew Morton <akpm@linux-foundation.org> > > +L: linux-kernel@vger.kernel.org > > +S: Supported > > Dunno. > > There are a lot of already specifically maintained or > supported files in lib/ > > Maybe be a reviewer? >
On Tue, 14 Nov 2023 21:38:50 -0800 Joe Perches <joe@perches.com> wrote: > > +LIBRARY CODE > > +M: Andrew Morton <akpm@linux-foundation.org> > > +L: linux-kernel@vger.kernel.org > > +S: Supported > > Dunno. > > There are a lot of already specifically maintained or > supported files in lib/ That's OK. I'll get printed out along with the existing list of maintainers, if any. > Maybe be a reviewer? Would that alter the get_maintainer output in any way? I suppose I could list each file individually, but I'm not sure what that would gain. btw, I see MAINTAINERS lists non-existent file[s] (lib/fw_table.c). Maybe someone has a script to check...
On Wed, 2023-11-15 at 14:34 -0800, Andrew Morton wrote: > On Tue, 14 Nov 2023 21:38:50 -0800 Joe Perches <joe@perches.com> wrote: > > > > +LIBRARY CODE > > > +M: Andrew Morton <akpm@linux-foundation.org> > > > +L: linux-kernel@vger.kernel.org > > > +S: Supported > > > > Dunno. > > > > There are a lot of already specifically maintained or > > supported files in lib/ > > That's OK. I'll get printed out along with the existing list of > maintainers, if any. > > > Maybe be a reviewer? > > Would that alter the get_maintainer output in any way? Not really. It would allow someone to avoid cc'ing reviewers and not maintainers though. Perhaps change the S: Supported to something like S: Supported for the files otherwise not supported > I suppose I could list each file individually, but I'm not sure what > that would gain. > > btw, I see MAINTAINERS lists non-existent file[s] (lib/fw_table.c). > Maybe someone has a script to check... --self-test works $ ./scripts/get_maintainer.pl --self-test=patterns ./MAINTAINERS:3653: warning: no file matches F: Documentation/devicetree/bindings/iio/imu/bosch,bma400.yaml ./MAINTAINERS:6126: warning: no file matches F: Documentation/devicetree/bindings/watchdog/da90??-wdt.txt ./MAINTAINERS:10342: warning: no file matches F: drivers/iio/light/gain-time-scale-helper.c ./MAINTAINERS:10343: warning: no file matches F: drivers/iio/light/gain-time-scale-helper.h ./MAINTAINERS:22062: warning: no file matches F: arch/arm/boot/dts/imx*mba*.dts* ./MAINTAINERS:22063: warning: no file matches F: arch/arm/boot/dts/imx*tqma*.dts* ./MAINTAINERS:22064: warning: no file matches F: arch/arm/boot/dts/mba*.dtsi and: see commit a103f46633fdcddc2aaca506420f177e8803a2bd $ git log --stat -1 a103f46633fdcddc2aaca506420f177e8803a2bd commit a103f46633fdcddc2aaca506420f177e8803a2bd Author: Dave Jiang <dave.jiang@intel.com> Date: Thu Oct 12 11:53:54 2023 -0700 acpi: Move common tables helper functions to common lib Some of the routines in ACPI driver/acpi/tables.c can be shared with parsing CDAT. CDAT is a device-provided data structure that is formatted similar to a platform provided ACPI table. CDAT is used by CXL and can exist on platforms that do not use ACPI. Split out the common routine from ACPI to accommodate platforms that do not support ACPI and move that to /lib. The common routines can be built outside of ACPI if FIRMWARE_TABLES is selected. Link: https://lore.kernel.org/linux-cxl/CAJZ5v0jipbtTNnsA0-o5ozOk8ZgWnOg34m34a9pPenTyRLj=6A@mail.gmail.com/ Suggested-by: "Rafael J. Wysocki" <rafael@kernel.org> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Acked-by: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/169713683430.2205276.17899451119920103445.stgit@djiang5-mobl3 Signed-off-by: Dan Williams <dan.j.williams@intel.com> MAINTAINERS | 2 ++ drivers/acpi/Kconfig | 1 + drivers/acpi/tables.c | 173 ------------------------------------------------------------------------------------------------------- include/linux/acpi.h | 42 +++++++------------------ include/linux/fw_table.h | 43 ++++++++++++++++++++++++++ lib/Kconfig | 3 ++ lib/Makefile | 2 ++ lib/fw_table.c | 189 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 8 files changed, 251 insertions(+), 204 deletions(-)
On Wed, 15 Nov 2023 14:48:38 -0800 Joe Perches <joe@perches.com> wrote: > > Would that alter the get_maintainer output in any way? > > Not really. It would allow someone to avoid cc'ing reviewers > and not maintainers though. > > Perhaps change the > S: Supported > to something like > S: Supported for the files otherwise not supported That's OK. I actually like to see what's going on in lib/. Sometimes I discover things in there that surprise me...
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan index fdca89c05745..935eda08b1e1 100644 --- a/lib/Kconfig.kasan +++ b/lib/Kconfig.kasan @@ -134,7 +134,7 @@ endchoice choice prompt "Instrumentation type" depends on KASAN_GENERIC || KASAN_SW_TAGS - default KASAN_OUTLINE + default KASAN_INLINE if !ARCH_DISABLE_KASAN_INLINE config KASAN_OUTLINE bool "Outline instrumentation"