All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Potapenko <glider@google.com>
To: Marco Elver <elver@google.com>
Cc: Wolfram Sang <wsa@the-dreams.de>,
	Vegard Nossum <vegard.nossum@oracle.com>,
	 Dmitry Vyukov <dvyukov@google.com>,
	Linux Memory Management List <linux-mm@kvack.org>,
	 Al Viro <viro@zeniv.linux.org.uk>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	 Andrew Morton <akpm@linux-foundation.org>,
	Andrey Konovalov <andreyknvl@google.com>,
	 Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Andy Lutomirski <luto@kernel.org>,
	 Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>,
	 Christoph Hellwig <hch@infradead.org>,
	Christoph Hellwig <hch@lst.de>,
	 "Darrick J. Wong" <darrick.wong@oracle.com>,
	David Miller <davem@davemloft.net>,
	 Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Eric Biggers <ebiggers@google.com>,
	 Eric Dumazet <edumazet@google.com>,
	Eric Van Hensbergen <ericvh@gmail.com>,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Harry Wentland <harry.wentland@amd.com>,
	 Herbert Xu <herbert@gondor.apana.org.au>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	 Ingo Molnar <mingo@elte.hu>, Jason Wang <jasowang@redhat.com>,
	Jens Axboe <axboe@kernel.dk>,
	 Marek Szyprowski <m.szyprowski@samsung.com>,
	Mark Rutland <mark.rutland@arm.com>,
	 "Martin K . Petersen" <martin.petersen@oracle.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	 Matthew Wilcox <willy@infradead.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Michal Simek <monstr@monstr.eu>,  Petr Mladek <pmladek@suse.com>,
	Qian Cai <cai@lca.pw>, Randy Dunlap <rdunlap@infradead.org>,
	 Robin Murphy <robin.murphy@arm.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	 Steven Rostedt <rostedt@goodmis.org>,
	Takashi Iwai <tiwai@suse.com>, "Theodore Ts'o" <tytso@mit.edu>,
	 Thomas Gleixner <tglx@linutronix.de>,
	Vasily Gorbik <gor@linux.ibm.com>
Subject: Re: [PATCH RFC v3 10/36] kmsan: add KMSAN runtime
Date: Thu, 19 Dec 2019 15:16:16 +0100	[thread overview]
Message-ID: <CAG_fn=UR7bb1MS3gyceBhY588TuqYjTetd-M0pTgpOdqOL1q0Q@mail.gmail.com> (raw)
In-Reply-To: <20191129160725.GA236510@google.com>

> Could all these just be using '.macro .endm'?
Done in v4

> > +__no_sanitize_memory
> > +static inline unsigned long KMSAN_INIT_8(unsigned long value)
> > +{
> > +     return value;
> > +}
>
> Should the above be __always_inline?

No. __always_inline forces a non-instrumented function to be inlined
into its instrumented caller, which results in the former being
instrumented. I've updated the comment to reflect that.

> Does it make sense to use u8, u16, u32, u64 here -- just in case it's
> ported to other architectures in future?

Done in v4.

> > +             default:                                        \
> > +                     BUILD_BUG_ON(1);                        \
> > +             }                                               \
> > +             __ret;                                          \
> > +     }) /**/
>
> Is the /**/ needed?

No, as long as we use .macro and .endm.

>
> It would be good to add doc comments to all API functions.

Done in v4

> > +extern bool kmsan_ready;
>
> What does this variable mean. Would 'kmsan_enabled' be more accurate?

I think kmsan_inited is a better name, if we want to change it at all.
kmsan_enabled somewhat implies KMSAN can be disabled.


> This is in include/linux -- do they need a KMSAN_ prefix to not clash
> with other definitions?

Done in v4.

> > +#define KMSAN_PARAM_SIZE 800
> > +
> > +#define PARAM_ARRAY_SIZE (KMSAN_PARAM_SIZE / sizeof(depot_stack_handle_t))
>
> Similar here -- does it need a KMSAN_ prefix?

Done in v4.

> > +void kmsan_clear_page(void *page_addr);
>
> It would be good to have doc comments for each of them.

Done in v4.

> > +
> > +KMSAN_SANITIZE := n
> > +KCOV_INSTRUMENT := n
>
> Does KMSAN work together with UBSAN? In that case may this needs a
> UBSAN_SANITIZE := n

Done

> > +#include <linux/stackdepot.h>
> > +#include <linux/stacktrace.h>
> > +#include <linux/types.h>
> > +#include <linux/vmalloc.h>
> > +
> > +#include <linux/mmzone.h>
>
> Why the space above the mmzone.h include?

Removed it, also fixed the include order for this file.

> > +/*
> > + * Some kernel asm() calls mention the non-existing |__force_order| variable
> > + * in the asm constraints to preserve the order of accesses to control
> > + * registers. KMSAN turns those mentions into actual memory accesses, therefore
> > + * the variable is now required to link the kernel.
> > + */
> > +unsigned long __force_order;
>
> Not sure if this is related, but when compiling with KMSAN I get
>
>         ERROR: "__force_order" [drivers/misc/lkdtm/lkdtm.ko] undefined!
>
> with a default config with KMSAN selected.

Added an EXPORT_SYMBOL to fix this.

>
> > +bool kmsan_ready;
> > +#define KMSAN_STACK_DEPTH 64
> > +#define MAX_CHAIN_DEPTH 7
>
> Should these defines be above the variable definitions?

Done


>
> Why not just 'panic("%s: ...", __func__, ...)' ?
>
> If the BUG() should not be here, then maybe just WARN_ON?

Replaced with panic().

> > +
> > +/*
> > + * TODO(glider): writing an initialized byte shouldn't zero out the origin, if
> > + * the remaining three bytes are uninitialized.
> > + */
>
> What needs to be done to address the TODO?  Just adding a comment is
> fine (or if the TODO can be resolved that's also fine).

Filed https://github.com/google/kmsan/issues/70 to track this. This
isn't a showstopper.

> > +     if (checked && !metadata_is_contiguous(addr, size, META_ORIGIN)) {
> > +             kmsan_pr_locked("WARNING: not setting origin for %d bytes starting at %px, because the metadata is incontiguous\n", size, addr);
> > +             BUG();
>
> Just panic?

Done.

> > +/*
> > + * TODO(glider): this check shouldn't be performed for origin pages, because
> > + * they're always accessed after the shadow pages.
> > + */
>
> What needs to be done to address the TODO?  Just adding a comment is
> fine (or if the TODO can be resolved that's also fine).

Dropped the TODO. This is somewhat perfectionist.

> > +     if (origin_p) {
> > +             kmsan_pr_locked("Origin: %08x\n", *origin_p);
> > +             kmsan_print_origin(*origin_p);
> > +     } else {
> > +             kmsan_pr_locked("Origin: unavailable\n");
> > +     }
>
> These repeated calls to kmsan_pr_locked seem unnecessary. There is
> nothing ensuring atomicity of all these print calls w.r.t. reporting.

Replaced them with pr_err().


> > +/* Stolen from kernel/printk/internal.h */
> > +#define PRINTK_SAFE_CONTEXT_MASK      0x3fffffff
>
> Is this used anywhere?

No. Removed it.

> > +/* Called by kmsan_report.c under a lock. */
> > +#define kmsan_pr_err(...) pr_err(__VA_ARGS__)
>
> Why is this macro needed? It's never redefined, so in the places it is
> used, you can just use pr_err. For readability I would avoid unnecessary
> aliases, but if there is a genuine reason this may be needed in future,
> I would just add a comment.

I've removed the macro.

> > +/* Used in other places - doesn't require a lock. */
> > +#define kmsan_pr_locked(...) \
> > +     do { \
> > +             unsigned long flags;                    \
> > +             spin_lock_irqsave(&report_lock, flags); \
> > +             pr_err(__VA_ARGS__); \
> > +             spin_unlock_irqrestore(&report_lock, flags); \
> > +     } while (0)
>
> Is this macro needed?  The only reason it sort of makes sense is to
> serialize a report with other printing, but otherwise pr_err already
> makes sure things are serialized properly.

Yes, this was the intention. On the other hand, this lock doesn't
prevent non-KMSAN code from messing up KMSAN reports, so it makes
little sense. Maybe we can just keep the spinlock to separate the
reports from each other.

> > +enum KMSAN_BUG_REASON {
> > +     REASON_ANY = 0,
> > +     REASON_COPY_TO_USER = 1,
> > +     REASON_USE_AFTER_FREE = 2,
> > +     REASON_SUBMIT_URB = 3,
> > +};
>
> Is it required to explicitly assign constants to these?

No. Removed the constants.

> > +#define LEAVE_RUNTIME(irq_flags)     \
> > +     do {    \
> > +             this_cpu_dec(kmsan_in_runtime); \
> > +             if (this_cpu_read(kmsan_in_runtime)) { \
> > +                     kmsan_pr_err("kmsan_in_runtime: %d\n", \
> > +                             this_cpu_read(kmsan_in_runtime)); \
> > +                     BUG(); \
> > +             }       \
> > +             restart_nmi();          \
> > +             local_irq_restore(irq_flags);   \
> > +             preempt_enable(); } while (0)
>
> Could these not be macros, and instead be static __always_inline
> functions?

Done

> > +static void kmsan_context_exit(void)
> > +{
> > +     int level = this_cpu_read(kmsan_context_level) - 1;
> > +
> > +     BUG_ON(level < 0);
> > +     this_cpu_write(kmsan_context_level, level);
> > +}
>
> These are not preemption-safe. this_cpu_dec_return followed by the
> BUG_ON should be sufficient. Similarly above and below (using
> this_cpu_add_return)

Good catch, thank you!

> > +void kmsan_interrupt_exit(void)
> > +{
> > +     int in_interrupt = this_cpu_read(kmsan_in_interrupt);
> > +
> > +     BUG_ON(!in_interrupt);
> > +     kmsan_context_exit();
> > +     /* Can't check preempt_count() here, it may be zero. */
> > +     this_cpu_write(kmsan_in_interrupt, in_interrupt - 1);
> > +}
> > +EXPORT_SYMBOL(kmsan_interrupt_exit);
>
> Why exactly does kmsan_in_interrupt need to be maintained here? I can't
> see them being used anywhere else. Is it only for the BUG_ON?

Yes, initially some consistency checks made sense. I think it's safe
to delete them now.

> > +void kmsan_softirq_exit(void)
> > +{
> > +     bool in_softirq = this_cpu_read(kmsan_in_softirq);
> > +
> > +     BUG_ON(!in_softirq);
> > +     kmsan_context_exit();
> > +     /* Can't check preempt_count() here, it may be zero. */
> > +     this_cpu_write(kmsan_in_softirq, false);
> > +}
> > +EXPORT_SYMBOL(kmsan_softirq_exit);
>
> Same question here for kmsan_in_softirq.

Ditto

> > +void kmsan_nmi_exit(void)
> > +{
> > +     bool in_nmi = this_cpu_read(kmsan_in_nmi);
> > +
> > +     BUG_ON(!in_nmi);
> > +     BUG_ON(preempt_count() & NMI_MASK);
> > +     kmsan_context_exit();
> > +     this_cpu_write(kmsan_in_nmi, false);
> > +
> > +}
> > +EXPORT_SYMBOL(kmsan_nmi_exit);
>
> And same question here for kmsan_in_nmi.

Ditto.

> > +
> > +/*
> > + * Record a range of memory for which the metadata pages will be created once
> > + * the page allocator becomes available.
> > + * TODO(glider): squash together ranges belonging to the same page.
> > + */
>
> What needs to be done to address the TODO?  Just adding a comment is
> fine (or if the TODO can be resolved that's also fine).

Removed the TODO. There's a problem with non-contiguous pages which is
tracked at https://github.com/google/kmsan/issues/71

> > +     /*
> > +      * TODO(glider): alloc_node_data() in arch/x86/mm/numa.c uses
> > +      * sizeof(pg_data_t).
> > +      */
>
> What needs to be done to address the TODO?  Just adding a comment is
> fine (or if the TODO can be resolved that's also fine).

Resolved this (the code is actually correct)

> > +
> > +     if (IN_RUNTIME()) {
> > +             /*
> > +              * TODO(glider): looks legit. depot_save_stack() may call
> > +              * free_pages().
> > +              */
>
> What needs to be done to address the TODO?  Just adding a comment is
> fine (or if the TODO can be resolved that's also fine).

I've just dropped this if-clause.

> > +             return;
> > +     }
> > +
> > +     ENTER_RUNTIME(irq_flags);
> > +     shadow = shadow_page_for(&page[0]);
> > +     origin = origin_page_for(&page[0]);
> > +
> > +     /* TODO(glider): this is racy. */
>
> Can this be fixed or does the race not matter -- in the latter case,
> just remove the TODO and turn it into a NOTE or similar.

It doesn't matter. Removed the comment.


-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg


  reply	other threads:[~2019-12-19 14:16 UTC|newest]

Thread overview: 120+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-22 11:25 [PATCH RFC v3 00/36] Add KernelMemorySanitizer infrastructure glider
2019-11-22 11:25 ` [PATCH RFC v3 01/36] stackdepot: check depot_index before accessing the stack slab glider
2019-11-27 14:22   ` Marco Elver
2019-11-22 11:25 ` [PATCH RFC v3 02/36] stackdepot: build with -fno-builtin glider
2019-11-27 14:22   ` Marco Elver
2019-11-22 11:25 ` [PATCH RFC v3 03/36] kasan: stackdepot: move filter_irq_stacks() to stackdepot.c glider
2019-11-27 14:22   ` Marco Elver
2019-11-27 14:56     ` Alexander Potapenko
2019-11-22 11:25 ` [PATCH RFC v3 04/36] stackdepot: reserve 5 extra bits in depot_stack_handle_t glider
2019-11-27 14:23   ` Marco Elver
2019-11-22 11:25 ` [PATCH RFC v3 05/36] kmsan: add ReST documentation glider
2019-11-27 14:22   ` Marco Elver
2019-12-03 12:42     ` Alexander Potapenko
2019-11-22 11:25 ` [PATCH RFC v3 06/36] kmsan: gfp: introduce __GFP_NO_KMSAN_SHADOW glider
2019-11-27 14:48   ` Marco Elver
2019-12-03 12:57     ` Alexander Potapenko
2019-11-22 11:25 ` [PATCH RFC v3 07/36] kmsan: introduce __no_sanitize_memory and __SANITIZE_MEMORY__ glider
2019-11-28 13:13   ` Marco Elver
2019-11-29 16:09   ` Andrey Konovalov
2019-12-16 11:35     ` Alexander Potapenko
2019-11-22 11:25 ` [PATCH RFC v3 08/36] kmsan: reduce vmalloc space glider
2019-11-28 13:30   ` Marco Elver
2019-11-22 11:25 ` [PATCH RFC v3 09/36] kmsan: add KMSAN bits to struct page and struct task_struct glider
2019-11-28 13:44   ` Marco Elver
2019-11-28 14:05     ` Alexander Potapenko
2019-11-22 11:25 ` [PATCH RFC v3 10/36] kmsan: add KMSAN runtime glider
2019-11-24 19:44   ` Wolfram Sang
2019-11-25  9:14     ` Alexander Potapenko
2019-11-29 16:07   ` Marco Elver
2019-12-19 14:16     ` Alexander Potapenko [this message]
2019-12-02 15:39   ` Andrey Konovalov
2019-12-20 18:58     ` Alexander Potapenko
2019-12-03 14:34   ` Andrey Konovalov
2019-11-22 11:25 ` [PATCH RFC v3 11/36] kmsan: stackdepot: don't allocate KMSAN metadata for stackdepot glider
2019-11-29 14:52   ` Andrey Konovalov
2019-12-03 14:27     ` Alexander Potapenko
2019-11-22 11:25 ` [PATCH RFC v3 12/36] kmsan: define READ_ONCE_NOCHECK() glider
2019-12-02 10:03   ` Marco Elver
2019-12-03 12:45     ` Alexander Potapenko
2019-11-22 11:25 ` [PATCH RFC v3 13/36] kmsan: make READ_ONCE_TASK_STACK() return initialized values glider
2019-12-02 10:07   ` Marco Elver
2019-12-05 15:52     ` Alexander Potapenko
2019-11-22 11:25 ` [PATCH RFC v3 14/36] kmsan: x86: sync metadata pages on page fault glider
2019-11-22 11:26 ` [PATCH RFC v3 15/36] kmsan: add tests for KMSAN glider
2019-11-29 14:14   ` Andrey Konovalov
2019-12-05 14:30     ` Alexander Potapenko
2019-11-22 11:26 ` [PATCH RFC v3 16/36] crypto: kmsan: disable accelerated configs under KMSAN glider
2019-12-02 13:25   ` Marco Elver
2019-12-05 14:51     ` Alexander Potapenko
2019-11-22 11:26 ` [PATCH RFC v3 17/36] kmsan: x86: disable UNWINDER_ORC " glider
2019-12-02 13:30   ` Marco Elver
2019-11-22 11:26 ` [PATCH RFC v3 18/36] kmsan: disable LOCK_DEBUGGING_SUPPORT glider
2019-12-02 13:33   ` Marco Elver
2019-12-03 14:34     ` Alexander Potapenko
2019-12-03 15:00       ` Qian Cai
2019-12-03 15:14         ` Alexander Potapenko
2019-12-03 18:02           ` Qian Cai
2019-12-03 18:38           ` Steven Rostedt
2019-12-04  8:41             ` Alexander Potapenko
2019-12-04 12:22               ` Petr Mladek
2019-12-04 13:12                 ` Qian Cai
2019-12-04 16:24                   ` Alexander Potapenko
2019-12-04 18:03                     ` Qian Cai
2019-11-22 11:26 ` [PATCH RFC v3 20/36] kmsan: x86: increase stack sizes in KMSAN builds glider
2019-12-02 14:31   ` Marco Elver
2019-11-22 11:26 ` [PATCH RFC v3 21/36] kmsan: disable KMSAN instrumentation for certain kernel parts glider
2019-11-29 15:07   ` Andrey Konovalov
2019-12-10 10:35     ` Alexander Potapenko
2019-12-10 12:38       ` Alexander Potapenko
2019-12-10 12:43       ` Qian Cai
2019-11-22 11:26 ` [PATCH RFC v3 22/36] kmsan: mm: call KMSAN hooks from SLUB code glider
2019-12-02 15:36   ` Marco Elver
2019-12-10 12:07     ` Alexander Potapenko
2019-11-22 11:26 ` [PATCH RFC v3 23/36] kmsan: call KMSAN hooks where needed glider
2019-11-26 10:17   ` Petr Mladek
2019-11-26 10:52     ` Alexander Potapenko
2019-11-29 16:21   ` Andrey Konovalov
2019-12-16 11:30     ` Alexander Potapenko
2019-11-22 11:26 ` [PATCH RFC v3 24/36] kmsan: disable instrumentation of certain functions glider
2019-11-29 14:59   ` Andrey Konovalov
2019-12-18 10:02     ` Alexander Potapenko
2019-11-22 11:26 ` [PATCH RFC v3 25/36] kmsan: unpoison |tlb| in arch_tlb_gather_mmu() glider
2019-11-29 15:08   ` Andrey Konovalov
2019-12-03 14:19     ` Alexander Potapenko
2019-11-22 11:26 ` [PATCH RFC v3 26/36] kmsan: use __msan_memcpy() where possible glider
2019-11-29 15:13   ` Andrey Konovalov
2019-12-05 15:46     ` Alexander Potapenko
2019-11-22 11:26 ` [PATCH RFC v3 27/36] kmsan: hooks for copy_to_user() and friends glider
2019-11-29 15:34   ` Andrey Konovalov
2019-12-05 16:00     ` Alexander Potapenko
2019-12-05 16:44       ` Andrey Konovalov
2019-12-11 14:22         ` Alexander Potapenko
2019-11-22 11:26 ` [PATCH RFC v3 28/36] kmsan: enable KMSAN builds glider
2019-11-29 15:55   ` Andrey Konovalov
2019-12-11 12:51     ` Alexander Potapenko
2019-11-22 11:26 ` [PATCH RFC v3 29/36] kmsan: handle /dev/[u]random glider
2019-11-22 11:26 ` [PATCH RFC v3 30/36] kmsan: virtio: check/unpoison scatterlist in vring_map_one_sg() glider
2019-11-22 11:26 ` [PATCH RFC v3 31/36] kmsan: disable strscpy() optimization under KMSAN glider
2019-12-02 15:51   ` Marco Elver
2019-12-02 16:23     ` Alexander Potapenko
2019-12-03 11:19       ` Alexander Potapenko
2019-12-03 11:24         ` Marco Elver
2019-12-03 11:27           ` Alexander Potapenko
2019-11-22 11:26 ` [PATCH RFC v3 32/36] kmsan: add iomap support glider
2019-12-03 12:50   ` Marco Elver
2019-12-03 14:07     ` Alexander Potapenko
2019-11-22 11:26 ` [PATCH RFC v3 33/36] kmsan: dma: unpoison memory mapped by dma_direct_map_page() glider
2019-11-22 11:26 ` [PATCH RFC v3 34/36] kmsan: disable physical page merging in biovec glider
2019-12-03 12:54   ` Marco Elver
2019-12-03 13:38     ` Alexander Potapenko
2019-11-22 11:26 ` [PATCH RFC v3 35/36] kmsan: ext4: skip block merging logic in ext4_mpage_readpages for KMSAN glider
2019-11-25 16:05   ` Robin Murphy
2019-11-25 17:03     ` Alexander Potapenko
2019-12-03 14:22   ` Marco Elver
2019-12-05 14:31     ` Alexander Potapenko
2019-11-22 11:26 ` [PATCH RFC v3 36/36] net: kasan: kmsan: support CONFIG_GENERIC_CSUM on x86, enable it for KASAN/KMSAN glider
2019-12-03 14:17   ` Marco Elver
2019-12-05 14:37     ` Alexander Potapenko
2019-11-29 14:39 ` [PATCH RFC v3 00/36] Add KernelMemorySanitizer infrastructure Marco Elver
2019-12-02 16:02   ` Alexander Potapenko

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='CAG_fn=UR7bb1MS3gyceBhY588TuqYjTetd-M0pTgpOdqOL1q0Q@mail.gmail.com' \
    --to=glider@google.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=aryabinin@virtuozzo.com \
    --cc=axboe@kernel.dk \
    --cc=cai@lca.pw \
    --cc=darrick.wong@oracle.com \
    --cc=davem@davemloft.net \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dvyukov@google.com \
    --cc=ebiggers@google.com \
    --cc=edumazet@google.com \
    --cc=elver@google.com \
    --cc=ericvh@gmail.com \
    --cc=gor@linux.ibm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=harry.wentland@amd.com \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=iii@linux.ibm.com \
    --cc=jasowang@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mark.rutland@arm.com \
    --cc=martin.petersen@oracle.com \
    --cc=mingo@elte.hu \
    --cc=monstr@monstr.eu \
    --cc=mst@redhat.com \
    --cc=pmladek@suse.com \
    --cc=rdunlap@infradead.org \
    --cc=robin.murphy@arm.com \
    --cc=rostedt@goodmis.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=tiwai@suse.com \
    --cc=tytso@mit.edu \
    --cc=vegard.nossum@oracle.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --cc=wsa@the-dreams.de \
    /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.