All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Andrey Konovalov <andreyknvl@google.com>
Cc: Julien Thierry <julien.thierry@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Christopher Li <sparse@chrisli.org>,
	Tyler Baicar <tbaicar@codeaurora.org>,
	Will Deacon <will.deacon@arm.com>,
	Paul Lawrence <paullawrence@google.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Yury Norov <ynorov@caviumnetworks.com>,
	Alexander Potapenko <glider@google.com>,
	Christoph Lameter <cl@linux.com>,
	Michael Weiser <michael.weiser@gmx.de>,
	kvmarm@lists.cs.columbia.edu, Kees Cook <keescook@google.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-doc@vger.kernel.org, Mark Brand <markbrand@google.com>,
	kasan-dev <kasan-dev@googlegroups.com>,
	linux-sparse@vger.kernel.org,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	David Rientjes <rientjes@google.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>
Subject: Re: [RFC PATCH v2 03/15] khwasan: add CONFIG_KASAN_CLASSIC and CONFIG_KASAN_TAGS
Date: Tue, 27 Mar 2018 22:02:23 +0200	[thread overview]
Message-ID: <20180327200223.5ku2eqkppi7z3sd2@gmail.com> (raw)
In-Reply-To: <CAAeHK+za1Zg2+1_CFrQbdn_Hwa9o_nZkHuMLaekV18W380jAoQ@mail.gmail.com>


* Andrey Konovalov <andreyknvl@google.com> wrote:

> On Sat, Mar 24, 2018 at 9:43 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Andrey Konovalov <andreyknvl@google.com> wrote:
> >
> >> This commit splits the current CONFIG_KASAN config option into two:
> >> 1. CONFIG_KASAN_CLASSIC, that enables the classic KASAN version (the one
> >>    that exists now);
> >> 2. CONFIG_KASAN_TAGS, that enables KHWASAN.
> >
> > Sorry, but this is pretty obscure naming scheme that doesn't explain the primary
> > difference between these KASAN models to users: that the first one is a pure
> > software implementation and the other is hardware-assisted.
> >
> > Reminds me of the transparency of galactic buerocracy in "The Hitchhiker's Guide
> > to the Galaxy":
> >
> >   “But look, you found the notice, didn’t you?”
> >   “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing
> >    cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the
> >    Leopard.”
> >
> > I'd suggest something more expressive, such as:
> >
> >         CONFIG_KASAN
> >           CONFIG_KASAN_GENERIC
> >           CONFIG_KASAN_HW_ASSIST
> >
> > or so?
> >
> > The 'generic' variant will basically run on any CPU. The 'hardware assisted' one
> > needs support from the CPU.
> >
> > The following ones might also work:
> >
> >    CONFIG_KASAN_HWASSIST
> >    CONFIG_KASAN_HW_TAGS
> >    CONFIG_KASAN_HWTAGS
> >
> > ... or simply CONFIG_KASAN_SW/CONFIG_KASAN_HW.
> >
> > If other types of KASAN hardware acceleration are implemented in the future then
> > the CONFIG_KASAN_HW namespace can be extended:
> >
> >         CONFIG_KASAN_HW_TAGS
> >         CONFIG_KASAN_HW_KEYS
> >         etc.
> 
> How about these two:
> 
> CONFIG_KASAN_GENERIC
> CONFIG_KASAN_HW
> 
> ?
> 
> Shorter config name looks better to me and I think it makes sense to
> name the new config just HW, as there's only one HW implementation
> right now. When (and if) there are more, we can expand the config name
> as you suggested (CONFIG_KASAN_HW_TAGS, CONFIG_KASAN_HW_KEYS, etc).

Sure, sounds good to me!

Thanks,

	Ingo
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Andrey Konovalov <andreyknvl@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Christopher Li <sparse@chrisli.org>,
	Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Michal Marek <michal.lkml@markovi.net>,
	Mark Rutland <mark.rutland@arm.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Yury Norov <ynorov@caviumnetworks.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Kristina Martsenko <kristina.martsenko@arm.com>,
	Punit Agrawal <punit.agrawal@arm.com>,
	Dave Martin <Dave.Martin@arm.com>,
	Michael Weiser <michael.weiser@gmx.de>,
	James Morse <james.morse@arm.com>,
	Julien Thierry <julien.thierry@arm.com>,
	Steve Capper <steve.capper@arm.com>,
	Tyler Baicar <tbaicar@codeaurora.org>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	Stephen Boyd <stephen.boyd@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Paul Lawrence <paullawrence@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	David Woodhouse <dwmw@amazon.co.uk>,
	Sandipan Das <sandipan@linux.vnet.ibm.com>,
	Kees Cook <keescook@chromium.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Arnd Bergmann <arnd@arndb.de>,
	kasan-dev <kasan-dev@googlegroups.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	kvmarm@lists.cs.columbia.edu, linux-sparse@vger.kernel.org,
	Linux Memory Management List <linux-mm@kvack.org>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Kostya Serebryany <kcc@google.com>,
	Evgeniy Stepanov <eugenis@google.com>,
	Lee Smith <Lee.Smith@arm.com>,
	Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
	Jacob Bramley <Jacob.Bramley@arm.com>,
	Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>,
	Kees Cook <keescook@google.com>, Jann Horn <jannh@google.com>,
	Mark Brand <markbrand@google.com>
Subject: Re: [RFC PATCH v2 03/15] khwasan: add CONFIG_KASAN_CLASSIC and CONFIG_KASAN_TAGS
Date: Tue, 27 Mar 2018 22:02:23 +0200	[thread overview]
Message-ID: <20180327200223.5ku2eqkppi7z3sd2@gmail.com> (raw)
In-Reply-To: <CAAeHK+za1Zg2+1_CFrQbdn_Hwa9o_nZkHuMLaekV18W380jAoQ@mail.gmail.com>


* Andrey Konovalov <andreyknvl@google.com> wrote:

> On Sat, Mar 24, 2018 at 9:43 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Andrey Konovalov <andreyknvl@google.com> wrote:
> >
> >> This commit splits the current CONFIG_KASAN config option into two:
> >> 1. CONFIG_KASAN_CLASSIC, that enables the classic KASAN version (the one
> >>    that exists now);
> >> 2. CONFIG_KASAN_TAGS, that enables KHWASAN.
> >
> > Sorry, but this is pretty obscure naming scheme that doesn't explain the primary
> > difference between these KASAN models to users: that the first one is a pure
> > software implementation and the other is hardware-assisted.
> >
> > Reminds me of the transparency of galactic buerocracy in "The Hitchhiker's Guide
> > to the Galaxy":
> >
> >   a??But look, you found the notice, didna??t you?a??
> >   a??Yes,a?? said Arthur, a??yes I did. It was on display in the bottom of a locked filing
> >    cabinet stuck in a disused lavatory with a sign on the door saying a??Beware of the
> >    Leopard.a??
> >
> > I'd suggest something more expressive, such as:
> >
> >         CONFIG_KASAN
> >           CONFIG_KASAN_GENERIC
> >           CONFIG_KASAN_HW_ASSIST
> >
> > or so?
> >
> > The 'generic' variant will basically run on any CPU. The 'hardware assisted' one
> > needs support from the CPU.
> >
> > The following ones might also work:
> >
> >    CONFIG_KASAN_HWASSIST
> >    CONFIG_KASAN_HW_TAGS
> >    CONFIG_KASAN_HWTAGS
> >
> > ... or simply CONFIG_KASAN_SW/CONFIG_KASAN_HW.
> >
> > If other types of KASAN hardware acceleration are implemented in the future then
> > the CONFIG_KASAN_HW namespace can be extended:
> >
> >         CONFIG_KASAN_HW_TAGS
> >         CONFIG_KASAN_HW_KEYS
> >         etc.
> 
> How about these two:
> 
> CONFIG_KASAN_GENERIC
> CONFIG_KASAN_HW
> 
> ?
> 
> Shorter config name looks better to me and I think it makes sense to
> name the new config just HW, as there's only one HW implementation
> right now. When (and if) there are more, we can expand the config name
> as you suggested (CONFIG_KASAN_HW_TAGS, CONFIG_KASAN_HW_KEYS, etc).

Sure, sounds good to me!

Thanks,

	Ingo

WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Andrey Konovalov <andreyknvl@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Christopher Li <sparse@chrisli.org>,
	Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Michal Marek <michal.lkml@markovi.net>,
	Mark Rutland <mark.rutland@arm.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Yury Norov <ynorov@caviumnetworks.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Kristina Martsenko <kristina.martsenko@arm.com>,
	Punit Agrawal <punit.agrawal@arm.com>,
	Dave Martin <Dave.Martin@arm.com>,
	Michael Weiser <michael.weiser@gmx.de>,
	James Morse <james.morse@arm.com>,
	Julien Thierry <julien.thierry@arm.com>,
	Steve Capper <steve.capper@arm.com>,
	Tyler Baicar <tbaicar@codeaurora.org>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	Stephen Boyd <stephen.boyd@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Paul Lawrence <paullawrence@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	David Woodhouse <dwmw@amazon.co.uk>,
	Sandipan Das <sandipan@linux.vnet.ibm.com>,
	Kees Cook <keescook@chromium.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Arnd Bergmann <arnd@arndb.de>,
	kasan-dev <kasan-dev@googlegroups.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	kvmarm@lists.cs.columbia.edu, linux-sparse@vger.kernel.org,
	Linux Memory Management List <linux-mm@kvack.org>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Kostya Serebryany <kcc@google.com>,
	Evgeniy Stepanov <eugenis@google.com>,
	Lee Smith <Lee.Smith@arm.com>,
	Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
	Jacob Bramley <Jacob.Bramley@arm.com>,
	Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>,
	Kees Cook <keescook@google.com>, Jann Horn <jannh@google.com>,
	Mark Brand <markbrand@google.com>
Subject: Re: [RFC PATCH v2 03/15] khwasan: add CONFIG_KASAN_CLASSIC and CONFIG_KASAN_TAGS
Date: Tue, 27 Mar 2018 22:02:23 +0200	[thread overview]
Message-ID: <20180327200223.5ku2eqkppi7z3sd2@gmail.com> (raw)
In-Reply-To: <CAAeHK+za1Zg2+1_CFrQbdn_Hwa9o_nZkHuMLaekV18W380jAoQ@mail.gmail.com>


* Andrey Konovalov <andreyknvl@google.com> wrote:

> On Sat, Mar 24, 2018 at 9:43 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Andrey Konovalov <andreyknvl@google.com> wrote:
> >
> >> This commit splits the current CONFIG_KASAN config option into two:
> >> 1. CONFIG_KASAN_CLASSIC, that enables the classic KASAN version (the one
> >>    that exists now);
> >> 2. CONFIG_KASAN_TAGS, that enables KHWASAN.
> >
> > Sorry, but this is pretty obscure naming scheme that doesn't explain the primary
> > difference between these KASAN models to users: that the first one is a pure
> > software implementation and the other is hardware-assisted.
> >
> > Reminds me of the transparency of galactic buerocracy in "The Hitchhiker's Guide
> > to the Galaxy":
> >
> >   “But look, you found the notice, didn’t you?”
> >   “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing
> >    cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the
> >    Leopard.”
> >
> > I'd suggest something more expressive, such as:
> >
> >         CONFIG_KASAN
> >           CONFIG_KASAN_GENERIC
> >           CONFIG_KASAN_HW_ASSIST
> >
> > or so?
> >
> > The 'generic' variant will basically run on any CPU. The 'hardware assisted' one
> > needs support from the CPU.
> >
> > The following ones might also work:
> >
> >    CONFIG_KASAN_HWASSIST
> >    CONFIG_KASAN_HW_TAGS
> >    CONFIG_KASAN_HWTAGS
> >
> > ... or simply CONFIG_KASAN_SW/CONFIG_KASAN_HW.
> >
> > If other types of KASAN hardware acceleration are implemented in the future then
> > the CONFIG_KASAN_HW namespace can be extended:
> >
> >         CONFIG_KASAN_HW_TAGS
> >         CONFIG_KASAN_HW_KEYS
> >         etc.
> 
> How about these two:
> 
> CONFIG_KASAN_GENERIC
> CONFIG_KASAN_HW
> 
> ?
> 
> Shorter config name looks better to me and I think it makes sense to
> name the new config just HW, as there's only one HW implementation
> right now. When (and if) there are more, we can expand the config name
> as you suggested (CONFIG_KASAN_HW_TAGS, CONFIG_KASAN_HW_KEYS, etc).

Sure, sounds good to me!

Thanks,

	Ingo

  reply	other threads:[~2018-03-27 19:54 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-23 18:05 [RFC PATCH v2 00/15] khwasan: kernel hardware assisted address sanitizer Andrey Konovalov
2018-03-23 18:05 ` Andrey Konovalov
2018-03-23 18:05 ` [RFC PATCH v2 01/15] khwasan, mm: change kasan hooks signatures Andrey Konovalov
2018-03-23 18:05   ` Andrey Konovalov
2018-03-23 18:05 ` [RFC PATCH v2 02/15] khwasan: move common kasan and khwasan code to common.c Andrey Konovalov
2018-03-23 18:05   ` Andrey Konovalov
2018-03-23 18:05 ` [RFC PATCH v2 03/15] khwasan: add CONFIG_KASAN_CLASSIC and CONFIG_KASAN_TAGS Andrey Konovalov
2018-03-23 18:05   ` Andrey Konovalov
2018-03-24  8:43   ` Ingo Molnar
2018-03-24  8:43     ` Ingo Molnar
2018-03-24  8:43     ` Ingo Molnar
2018-03-27 16:23     ` Andrey Konovalov
2018-03-27 16:23       ` Andrey Konovalov
2018-03-27 20:02       ` Ingo Molnar [this message]
2018-03-27 20:02         ` Ingo Molnar
2018-03-27 20:02         ` Ingo Molnar
2018-03-23 18:05 ` [RFC PATCH v2 04/15] khwasan, arm64: adjust shadow size for CONFIG_KASAN_TAGS Andrey Konovalov
2018-03-23 18:05   ` Andrey Konovalov
2018-03-23 18:05 ` [RFC PATCH v2 05/15] khwasan: initialize shadow to 0xff Andrey Konovalov
2018-03-23 18:05   ` Andrey Konovalov
2018-03-30 16:07   ` Andrey Ryabinin
2018-03-30 16:07     ` Andrey Ryabinin
2018-04-03 14:43     ` Andrey Konovalov
2018-04-03 14:43       ` Andrey Konovalov
2018-03-23 18:05 ` [RFC PATCH v2 06/15] khwasan, arm64: untag virt address in __kimg_to_phys Andrey Konovalov
2018-03-23 18:05   ` Andrey Konovalov
2018-03-23 18:05 ` [RFC PATCH v2 07/15] khwasan, arm64: fix up fault handling logic Andrey Konovalov
2018-03-23 18:05   ` Andrey Konovalov
2018-03-23 18:05 ` [RFC PATCH v2 08/15] khwasan: add tag related helper functions Andrey Konovalov
2018-03-23 18:05   ` Andrey Konovalov
2018-03-23 18:05   ` Andrey Konovalov
2018-03-30 16:13   ` Andrey Ryabinin
2018-03-30 16:13     ` Andrey Ryabinin
2018-04-03 14:45     ` Andrey Konovalov
2018-04-03 14:45       ` Andrey Konovalov
2018-03-23 18:05 ` [RFC PATCH v2 09/15] khwasan, kvm: untag pointers in kern_hyp_va Andrey Konovalov
2018-03-23 18:05   ` Andrey Konovalov
2018-03-23 18:05 ` [RFC PATCH v2 10/15] khwasan, arm64: enable top byte ignore for the kernel Andrey Konovalov
2018-03-23 18:05   ` Andrey Konovalov
2018-03-23 18:05 ` [RFC PATCH v2 11/15] khwasan, mm: perform untagged pointers comparison in krealloc Andrey Konovalov
2018-03-23 18:05   ` Andrey Konovalov
2018-03-24  8:29   ` Ingo Molnar
2018-03-24  8:29     ` Ingo Molnar
2018-03-27 12:20     ` Andrey Konovalov
2018-03-27 12:20       ` Andrey Konovalov
2018-03-27 20:01       ` Ingo Molnar
2018-03-27 20:01         ` Ingo Molnar
2018-03-23 18:05 ` [RFC PATCH v2 12/15] khwasan: add bug reporting routines Andrey Konovalov
2018-03-23 18:05   ` Andrey Konovalov
2018-03-23 18:05 ` [RFC PATCH v2 13/15] khwasan: add hooks implementation Andrey Konovalov
2018-03-23 18:05   ` Andrey Konovalov
2018-03-30 17:47   ` Andrey Ryabinin
2018-03-30 17:47     ` Andrey Ryabinin
2018-04-03 14:59     ` Andrey Konovalov
2018-04-03 14:59       ` Andrey Konovalov
2018-04-04 12:39       ` Andrey Ryabinin
2018-04-04 12:39         ` Andrey Ryabinin
2018-04-04 17:00         ` Andrey Konovalov
2018-04-04 17:00           ` Andrey Konovalov
2018-04-05 13:02           ` Andrey Ryabinin
2018-04-05 13:02             ` Andrey Ryabinin
2018-04-06 12:14             ` Andrey Konovalov
2018-04-06 12:14               ` Andrey Konovalov
2018-04-06 12:27               ` Andrey Ryabinin
2018-04-06 12:27                 ` Andrey Ryabinin
2018-04-10 16:07                 ` Andrey Konovalov
2018-04-10 16:07                   ` Andrey Konovalov
2018-04-10 16:31                   ` Andrey Ryabinin
2018-04-12 16:45                     ` Andrey Konovalov
2018-04-12 16:45                       ` Andrey Konovalov
2018-04-12 17:20                       ` Andrey Ryabinin
2018-04-12 17:20                         ` Andrey Ryabinin
2018-04-12 17:37                         ` Andrey Konovalov
2018-04-12 17:37                           ` Andrey Konovalov
2018-03-23 18:05 ` [RFC PATCH v2 14/15] khwasan, arm64: add brk handler for inline instrumentation Andrey Konovalov
2018-03-23 18:05   ` Andrey Konovalov
2018-03-23 18:05 ` [RFC PATCH v2 15/15] khwasan: update kasan documentation Andrey Konovalov
2018-03-23 18:05   ` Andrey Konovalov

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=20180327200223.5ku2eqkppi7z3sd2@gmail.com \
    --to=mingo@kernel.org \
    --cc=andreyknvl@google.com \
    --cc=aryabinin@virtuozzo.com \
    --cc=catalin.marinas@arm.com \
    --cc=cl@linux.com \
    --cc=corbet@lwn.net \
    --cc=geert@linux-m68k.org \
    --cc=glider@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=julien.thierry@arm.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=keescook@google.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=markbrand@google.com \
    --cc=michael.weiser@gmx.de \
    --cc=paullawrence@google.com \
    --cc=rientjes@google.com \
    --cc=sparse@chrisli.org \
    --cc=tbaicar@codeaurora.org \
    --cc=will.deacon@arm.com \
    --cc=yamada.masahiro@socionext.com \
    --cc=ynorov@caviumnetworks.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.