linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: Andrey Konovalov <andreyknvl@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Alexander Potapenko <glider@google.com>,
	Evgenii Stepanov <eugenis@google.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Elena Petrova <lenaptr@google.com>,
	Branislav Rankov <Branislav.Rankov@arm.com>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	kasan-dev <kasan-dev@googlegroups.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Serban Constantinescu <serbanc@google.com>,
	Kostya Serebryany <kcc@google.com>
Subject: Re: [PATCH RFC 0/8] kasan: hardware tag-based mode for production use on arm64
Date: Mon, 19 Oct 2020 14:23:20 +0200	[thread overview]
Message-ID: <CANpmjNN3Ax2_CfxXixh8-NipXOx7s8vprg23ua-M_tvUKZGq0Q@mail.gmail.com> (raw)
In-Reply-To: <cover.1602708025.git.andreyknvl@google.com>

On Wed, 14 Oct 2020 at 22:44, Andrey Konovalov <andreyknvl@google.com> wrote:
[...]
> A question to KASAN maintainers: what would be the best way to support the
> "off" mode? I see two potential approaches: add a check into each kasan
> callback (easier to implement, but we still call kasan callbacks, even
> though they immediately return), or add inline header wrappers that do the
> same.

This is tricky, because we don't know how bad the performance will be
if we keep them as calls. We'd have to understand the performance
impact of keeping them as calls, and if the performance impact is
acceptable or not.

Without understanding the performance impact, the only viable option I
see is to add __always_inline kasan_foo() wrappers, which use the
static branch to guard calls to __kasan_foo().

Thanks,
-- Marco

  parent reply	other threads:[~2020-10-19 12:23 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-14 20:44 [PATCH RFC 0/8] kasan: hardware tag-based mode for production use on arm64 Andrey Konovalov
2020-10-14 20:44 ` [PATCH RFC 1/8] kasan: simplify quarantine_put call Andrey Konovalov
2020-10-14 20:44 ` [PATCH RFC 2/8] kasan: rename get_alloc/free_info Andrey Konovalov
2020-10-14 20:44 ` [PATCH RFC 3/8] kasan: introduce set_alloc_info Andrey Konovalov
2020-10-14 20:44 ` [PATCH RFC 4/8] kasan: unpoison stack only with CONFIG_KASAN_STACK Andrey Konovalov
2020-10-14 20:44 ` [PATCH RFC 5/8] kasan: mark kasan_init_tags as __init Andrey Konovalov
2020-10-15 10:23   ` Marco Elver
2020-10-16 13:04     ` Andrey Konovalov
2020-10-14 20:44 ` [PATCH RFC 6/8] kasan, arm64: move initialization message Andrey Konovalov
2020-10-14 20:44 ` [PATCH RFC 7/8] arm64: kasan: Add system_supports_tags helper Andrey Konovalov
     [not found]   ` <20201020062248.1966-1-hdanton@sina.com>
2020-10-20 12:39     ` Andrey Konovalov
2020-10-14 20:44 ` [PATCH RFC 8/8] kasan: add and integrate kasan_mode boot param Andrey Konovalov
2020-10-15 13:56   ` Marco Elver
2020-10-16 13:10     ` Andrey Konovalov
2020-10-15 14:41 ` [PATCH RFC 0/8] kasan: hardware tag-based mode for production use on arm64 Marco Elver
2020-10-16 13:17   ` Andrey Konovalov
2020-10-16 13:31     ` Marco Elver
2020-10-16 15:52       ` Andrey Konovalov
2020-10-19 22:51         ` Kostya Serebryany
2020-10-20  5:34           ` Dmitry Vyukov
2020-10-20 12:13             ` Andrey Konovalov
2020-10-16 15:52   ` Andrey Konovalov
2020-10-16 15:50 ` Andrey Konovalov
2020-10-19 12:23 ` Marco Elver [this message]
2020-10-20  5:20   ` Dmitry Vyukov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANpmjNN3Ax2_CfxXixh8-NipXOx7s8vprg23ua-M_tvUKZGq0Q@mail.gmail.com \
    --to=elver@google.com \
    --cc=Branislav.Rankov@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=aryabinin@virtuozzo.com \
    --cc=catalin.marinas@arm.com \
    --cc=dvyukov@google.com \
    --cc=eugenis@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=kcc@google.com \
    --cc=kevin.brodsky@arm.com \
    --cc=lenaptr@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=serbanc@google.com \
    --cc=vincenzo.frascino@arm.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).