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
next prev parent 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).