linux-mm.kvack.org archive mirror
 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 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).