From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "jannh@google.com" <jannh@google.com>
Cc: "bsingharora@gmail.com" <bsingharora@gmail.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"Syromiatnikov, Eugene" <esyr@redhat.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"rdunlap@infradead.org" <rdunlap@infradead.org>,
"keescook@chromium.org" <keescook@chromium.org>,
"Yu, Yu-cheng" <yu-cheng.yu@intel.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"Eranian, Stephane" <eranian@google.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"fweimer@redhat.com" <fweimer@redhat.com>,
"nadav.amit@gmail.com" <nadav.amit@gmail.com>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"kcc@google.com" <kcc@google.com>, "bp@alien8.de" <bp@alien8.de>,
"oleg@redhat.com" <oleg@redhat.com>,
"hjl.tools@gmail.com" <hjl.tools@gmail.com>,
"Yang, Weijiang" <weijiang.yang@intel.com>,
"Lutomirski, Andy" <luto@kernel.org>,
"pavel@ucw.cz" <pavel@ucw.cz>, "arnd@arndb.de" <arnd@arndb.de>,
"Moreira, Joao" <joao.moreira@intel.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mike.kravetz@oracle.com" <mike.kravetz@oracle.com>,
"x86@kernel.org" <x86@kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"dave.martin@arm.com" <dave.martin@arm.com>,
"john.allen@amd.com" <john.allen@amd.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"Shankar, Ravi V" <ravi.v.shankar@intel.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
"gorcunov@gmail.com" <gorcunov@gmail.com>
Subject: Re: [PATCH 26/35] x86/process: Change copy_thread() argument 'arg' to 'stack_size'
Date: Tue, 15 Feb 2022 01:22:04 +0000 [thread overview]
Message-ID: <959707bff94b3a54f05cfcfc09fa809f08152807.camel@intel.com> (raw)
In-Reply-To: <CAG48ez0_Ng8Fv4ytLK=Y5ANXiDfBPsFFwfxQTzgmDjU1RNFnDw@mail.gmail.com>
On Mon, 2022-02-14 at 13:33 +0100, Jann Horn wrote:
> On Sun, Jan 30, 2022 at 10:22 PM Rick Edgecombe
> <rick.p.edgecombe@intel.com> wrote:
> >
> > From: Yu-cheng Yu <yu-cheng.yu@intel.com>
> >
> > The single call site of copy_thread() passes stack size in
> > 'arg'. To make
> > this clear and in preparation of using this argument for shadow
> > stack
> > allocation, change 'arg' to 'stack_size'. No functional changes.
>
> Actually that name is misleading - the single caller copy_process()
> indeed does:
>
> retval = copy_thread(clone_flags, args->stack, args->stack_size, p,
> args->tls);
>
> but the member "stack_size" of "struct kernel_clone_args" can
> actually
> also be a pointer argument given to a kthread, see create_io_thread()
> and kernel_thread():
>
> pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long
> flags)
> {
> struct kernel_clone_args args = {
> .flags = ((lower_32_bits(flags) | CLONE_VM |
> CLONE_UNTRACED) & ~CSIGNAL),
> .exit_signal = (lower_32_bits(flags) & CSIGNAL),
> .stack = (unsigned long)fn,
> .stack_size = (unsigned long)arg,
> };
>
> return kernel_clone(&args);
> }
>
> And then in copy_thread(), we have:
>
> kthread_frame_init(frame, sp, arg)
>
>
> So I'm not sure whether this name change really makes sense, or
> whether it just adds to the confusion.
Thanks Jann. Yea I guess this makes it worse.
Reading a bit of the history, it seems there used to be unwieldy
argument lists which were replaced by a big "struct kernel_clone_args"
to be passed around. The re-use of the stack_size argument is from
before there was the struct. And then the struct just inherited the
confusion when it was introduced.
So if a separate *data member was added to kernel_clone_args for
kernel_thread() and create_io_thread() to use, they wouldn't need to
re-use stack_size. And copy_thread() could just take a struct
kernel_clone_args pointer. It might make it more clear.
But copy_thread() has a ton of arch specific implementations. So they
would all need to be updated to do this.
Just playing around with it, I did this which only makes the change on
x86. Duplicating it for 21 copy_thread()s seems perfectly doable, but
I'm not sure how much people care vs renaming arg to
stacksize_or_data...
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 11bf09b60f9d..cfbba5b14609 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -132,9 +132,8 @@ static int set_new_tls(struct task_struct *p,
unsigned long tls)
return do_set_thread_area_64(p, ARCH_SET_FS, tls);
}
-int copy_thread(unsigned long clone_flags, unsigned long sp,
- unsigned long stack_size, struct task_struct *p,
- unsigned long tls)
+int copy_thread(unsigned long clone_flags, struct kernel_clone_args
*args,
+ struct task_struct *p)
{
struct inactive_task_frame *frame;
struct fork_frame *fork_frame;
@@ -178,7 +177,7 @@ int copy_thread(unsigned long clone_flags, unsigned
long sp,
if (unlikely(p->flags & PF_KTHREAD)) {
p->thread.pkru = pkru_get_init_value();
memset(childregs, 0, sizeof(struct pt_regs));
- kthread_frame_init(frame, sp, stack_size);
+ kthread_frame_init(frame, args->stack, (unsigned
long)args->data);
return 0;
}
@@ -191,8 +190,8 @@ int copy_thread(unsigned long clone_flags, unsigned
long sp,
frame->bx = 0;
*childregs = *current_pt_regs();
childregs->ax = 0;
- if (sp)
- childregs->sp = sp;
+ if (args->stack)
+ childregs->sp = args->stack;
#ifdef CONFIG_X86_32
task_user_gs(p) = get_user_gs(current_pt_regs());
@@ -211,17 +210,17 @@ int copy_thread(unsigned long clone_flags,
unsigned long sp,
*/
childregs->sp = 0;
childregs->ip = 0;
- kthread_frame_init(frame, sp, stack_size);
+ kthread_frame_init(frame, args->stack, (unsigned
long)args->data);
return 0;
}
/* Set a new TLS for the child thread? */
if (clone_flags & CLONE_SETTLS)
- ret = set_new_tls(p, tls);
+ ret = set_new_tls(p, args->tls);
/* Allocate a new shadow stack for pthread */
if (!ret)
- ret = shstk_alloc_thread_stack(p, clone_flags,
stack_size);
+ ret = shstk_alloc_thread_stack(p, clone_flags, args-
>stack_size);
if (!ret && unlikely(test_tsk_thread_flag(current,
TIF_IO_BITMAP)))
io_bitmap_share(p);
diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h
index b9198a1b3a84..f138b23aee50 100644
--- a/include/linux/sched/task.h
+++ b/include/linux/sched/task.h
@@ -34,6 +34,7 @@ struct kernel_clone_args {
int io_thread;
struct cgroup *cgrp;
struct css_set *cset;
+ void *data;
};
/*
@@ -67,8 +68,8 @@ extern void fork_init(void);
extern void release_task(struct task_struct * p);
-extern int copy_thread(unsigned long, unsigned long, unsigned long,
- struct task_struct *, unsigned long);
+extern int copy_thread(unsigned long clone_flags, struct
kernel_clone_args *args,
+ struct task_struct *p);
extern void flush_thread(void);
@@ -85,10 +86,10 @@ extern void exit_files(struct task_struct *);
extern void exit_itimers(struct signal_struct *);
extern pid_t kernel_clone(struct kernel_clone_args *kargs);
-struct task_struct *create_io_thread(int (*fn)(void *), void *arg, int
node);
+struct task_struct *create_io_thread(int (*fn)(void *), void *data,
int node);
struct task_struct *fork_idle(int);
struct mm_struct *copy_init_mm(void);
-extern pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long
flags);
+extern pid_t kernel_thread(int (*fn)(void *), void *data, unsigned
long flags);
extern long kernel_wait4(pid_t, int __user *, int, struct rusage *);
int kernel_wait(pid_t pid, int *stat);
diff --git a/kernel/fork.c b/kernel/fork.c
index d75a528f7b21..8af202e5651e 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2170,7 +2170,7 @@ static __latent_entropy struct task_struct
*copy_process(
retval = copy_io(clone_flags, p);
if (retval)
goto bad_fork_cleanup_namespaces;
- retval = copy_thread(clone_flags, args->stack, args-
>stack_size, p, args->tls);
+ retval = copy_thread(clone_flags, args, p);
if (retval)
goto bad_fork_cleanup_io;
@@ -2487,7 +2487,7 @@ struct mm_struct *copy_init_mm(void)
* The returned task is inactive, and the caller must fire it up
through
* wake_up_new_task(p). All signals are blocked in the created task.
*/
-struct task_struct *create_io_thread(int (*fn)(void *), void *arg, int
node)
+struct task_struct *create_io_thread(int (*fn)(void *), void *data,
int node)
{
unsigned long flags =
CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|
CLONE_IO;
@@ -2496,7 +2496,7 @@ struct task_struct *create_io_thread(int
(*fn)(void *), void *arg, int node)
CLONE_UNTRACED) & ~CSIGNAL),
.exit_signal = (lower_32_bits(flags) & CSIGNAL),
.stack = (unsigned long)fn,
- .stack_size = (unsigned long)arg,
+ .data = data,
.io_thread = 1,
};
@@ -2594,14 +2594,14 @@ pid_t kernel_clone(struct kernel_clone_args
*args)
/*
* Create a kernel thread.
*/
-pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
+pid_t kernel_thread(int (*fn)(void *), void *data, unsigned long
flags)
{
struct kernel_clone_args args = {
.flags = ((lower_32_bits(flags) | CLONE_VM |
CLONE_UNTRACED) & ~CSIGNAL),
.exit_signal = (lower_32_bits(flags) & CSIGNAL),
.stack = (unsigned long)fn,
- .stack_size = (unsigned long)arg,
+ .data = data,
};
return kernel_clone(&args);
next prev parent reply other threads:[~2022-02-15 1:22 UTC|newest]
Thread overview: 152+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-30 21:18 [PATCH 00/35] Shadow stacks for userspace Rick Edgecombe
2022-01-30 21:18 ` [PATCH 01/35] Documentation/x86: Add CET description Rick Edgecombe
2022-01-30 21:18 ` [PATCH 02/35] x86/cet/shstk: Add Kconfig option for Shadow Stack Rick Edgecombe
2022-02-07 22:39 ` Dave Hansen
2022-02-08 8:41 ` Thomas Gleixner
2022-02-08 20:20 ` Edgecombe, Rick P
2022-02-08 8:39 ` Thomas Gleixner
2022-01-30 21:18 ` [PATCH 03/35] x86/cpufeatures: Add CET CPU feature flags for Control-flow Enforcement Technology (CET) Rick Edgecombe
2022-02-07 22:45 ` Dave Hansen
2022-02-08 20:23 ` Edgecombe, Rick P
2022-02-09 1:10 ` Kees Cook
2022-01-30 21:18 ` [PATCH 04/35] x86/cpufeatures: Introduce CPU setup and option parsing for CET Rick Edgecombe
2022-02-07 22:49 ` Dave Hansen
2022-02-08 20:29 ` Edgecombe, Rick P
2022-01-30 21:18 ` [PATCH 05/35] x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states Rick Edgecombe
2022-02-07 23:28 ` Dave Hansen
2022-02-08 21:36 ` Edgecombe, Rick P
2022-01-30 21:18 ` [PATCH 06/35] x86/cet: Add control-protection fault handler Rick Edgecombe
2022-02-07 23:56 ` Dave Hansen
2022-02-08 22:23 ` Edgecombe, Rick P
2022-01-30 21:18 ` [PATCH 07/35] x86/mm: Remove _PAGE_DIRTY from kernel RO pages Rick Edgecombe
2022-02-08 0:13 ` Dave Hansen
2022-02-08 22:52 ` Edgecombe, Rick P
2022-01-30 21:18 ` [PATCH 08/35] x86/mm: Move pmd_write(), pud_write() up in the file Rick Edgecombe
2022-01-30 21:18 ` [PATCH 09/35] x86/mm: Introduce _PAGE_COW Rick Edgecombe
2022-02-08 1:05 ` Dave Hansen
2022-01-30 21:18 ` [PATCH 10/35] drm/i915/gvt: Change _PAGE_DIRTY to _PAGE_DIRTY_BITS Rick Edgecombe
2022-02-09 16:58 ` Dave Hansen
2022-02-11 1:39 ` Edgecombe, Rick P
2022-02-11 7:13 ` Wang, Zhi A
2022-02-12 1:45 ` Edgecombe, Rick P
2022-01-30 21:18 ` [PATCH 11/35] x86/mm: Update pte_modify for _PAGE_COW Rick Edgecombe
2022-02-09 18:00 ` Dave Hansen
2022-01-30 21:18 ` [PATCH 12/35] x86/mm: Update ptep_set_wrprotect() and pmdp_set_wrprotect() for transition from _PAGE_DIRTY to _PAGE_COW Rick Edgecombe
2022-02-09 18:30 ` Dave Hansen
2022-01-30 21:18 ` [PATCH 13/35] mm: Move VM_UFFD_MINOR_BIT from 37 to 38 Rick Edgecombe
2022-01-30 21:18 ` [PATCH 14/35] mm: Introduce VM_SHADOW_STACK for shadow stack memory Rick Edgecombe
2022-02-09 21:55 ` Dave Hansen
2022-01-30 21:18 ` [PATCH 15/35] x86/mm: Check Shadow Stack page fault errors Rick Edgecombe
2022-02-09 19:06 ` Dave Hansen
2022-01-30 21:18 ` [PATCH 16/35] x86/mm: Update maybe_mkwrite() for shadow stack Rick Edgecombe
2022-02-09 21:16 ` Dave Hansen
2022-01-30 21:18 ` [PATCH 17/35] mm: Fixup places that call pte_mkwrite() directly Rick Edgecombe
2022-02-09 21:51 ` Dave Hansen
2022-01-30 21:18 ` [PATCH 18/35] mm: Add guard pages around a shadow stack Rick Edgecombe
2022-02-09 22:23 ` Dave Hansen
2022-02-10 22:38 ` David Laight
2022-02-10 23:42 ` Edgecombe, Rick P
2022-02-11 9:08 ` David Laight
2022-02-10 22:43 ` Dave Hansen
2022-02-10 23:07 ` Andy Lutomirski
2022-02-10 23:40 ` Edgecombe, Rick P
2022-02-11 17:54 ` Andy Lutomirski
2022-02-12 0:10 ` Edgecombe, Rick P
2022-01-30 21:18 ` [PATCH 19/35] mm/mmap: Add shadow stack pages to memory accounting Rick Edgecombe
2022-02-09 22:27 ` Dave Hansen
2022-01-30 21:18 ` [PATCH 20/35] mm: Update can_follow_write_pte() for shadow stack Rick Edgecombe
2022-02-09 22:50 ` Dave Hansen
2022-02-09 22:52 ` Dave Hansen
2022-02-10 22:45 ` David Laight
2022-01-30 21:18 ` [PATCH 21/35] mm/mprotect: Exclude shadow stack from preserve_write Rick Edgecombe
2022-02-10 19:27 ` Dave Hansen
2022-01-30 21:18 ` [PATCH 22/35] x86/mm: Prevent VM_WRITE shadow stacks Rick Edgecombe
2022-02-11 22:19 ` Dave Hansen
2022-02-12 1:44 ` Edgecombe, Rick P
2022-01-30 21:18 ` [PATCH 23/35] x86/fpu: Add helpers for modifying supervisor xstate Rick Edgecombe
2022-02-08 8:51 ` Thomas Gleixner
2022-02-09 19:55 ` Edgecombe, Rick P
2022-02-12 0:27 ` Dave Hansen
2022-02-12 2:31 ` Edgecombe, Rick P
2022-01-30 21:18 ` [PATCH 24/35] mm: Re-introduce vm_flags to do_mmap() Rick Edgecombe
2022-01-30 21:18 ` [PATCH 25/35] x86/cet/shstk: Add user-mode shadow stack support Rick Edgecombe
2022-02-11 23:37 ` Dave Hansen
2022-02-12 0:07 ` Andy Lutomirski
2022-02-12 0:11 ` Dave Hansen
2022-02-12 0:12 ` Edgecombe, Rick P
2022-01-30 21:18 ` [PATCH 26/35] x86/process: Change copy_thread() argument 'arg' to 'stack_size' Rick Edgecombe
2022-02-08 8:38 ` Thomas Gleixner
2022-02-11 2:09 ` Edgecombe, Rick P
2022-02-14 12:33 ` Jann Horn
2022-02-15 1:22 ` Edgecombe, Rick P [this message]
2022-02-15 8:49 ` Christian Brauner
2022-01-30 21:18 ` [PATCH 27/35] x86/fpu: Add unsafe xsave buffer helpers Rick Edgecombe
2022-01-30 21:18 ` [PATCH 28/35] x86/cet/shstk: Handle thread shadow stack Rick Edgecombe
2022-01-30 21:18 ` [PATCH 29/35] x86/cet/shstk: Introduce shadow stack token setup/verify routines Rick Edgecombe
2022-01-30 21:18 ` [PATCH 30/35] x86/cet/shstk: Handle signals for shadow stack Rick Edgecombe
2022-01-30 21:18 ` [PATCH 31/35] x86/cet/shstk: Add arch_prctl elf feature functions Rick Edgecombe
2022-01-30 21:18 ` [PATCH 32/35] x86/cet/shstk: Introduce map_shadow_stack syscall Rick Edgecombe
2022-01-30 21:18 ` [PATCH 33/35] selftests/x86: Add map_shadow_stack syscall test Rick Edgecombe
2022-02-03 22:42 ` Dave Hansen
2022-02-04 1:22 ` Edgecombe, Rick P
2022-01-30 21:18 ` [PATCH 34/35] x86/cet/shstk: Support wrss for userspace Rick Edgecombe
2022-01-31 7:56 ` Florian Weimer
2022-01-31 18:26 ` H.J. Lu
2022-01-31 18:45 ` Florian Weimer
2022-01-30 21:18 ` [PATCH 35/35] x86/cpufeatures: Limit shadow stack to Intel CPUs Rick Edgecombe
2022-02-03 21:58 ` John Allen
2022-02-03 22:23 ` H.J. Lu
2022-02-04 22:21 ` John Allen
2022-02-03 21:07 ` [PATCH 00/35] Shadow stacks for userspace Thomas Gleixner
2022-02-04 1:08 ` Edgecombe, Rick P
2022-02-04 5:20 ` Andy Lutomirski
2022-02-04 20:23 ` Edgecombe, Rick P
2022-02-05 13:26 ` David Laight
2022-02-05 13:29 ` H.J. Lu
2022-02-05 20:15 ` Edgecombe, Rick P
2022-02-05 20:21 ` H.J. Lu
2022-02-06 13:19 ` Peter Zijlstra
2022-02-06 13:42 ` David Laight
2022-02-06 13:55 ` H.J. Lu
2022-02-07 10:22 ` Florian Weimer
2022-02-08 1:46 ` Edgecombe, Rick P
2022-02-08 1:31 ` Andy Lutomirski
2022-02-08 9:31 ` Thomas Gleixner
2022-02-08 16:15 ` Andy Lutomirski
2022-02-06 13:06 ` Peter Zijlstra
2022-02-06 18:42 ` Mike Rapoport
2022-02-07 7:20 ` Adrian Reber
2022-02-07 16:30 ` Dave Hansen
2022-02-08 9:16 ` Mike Rapoport
2022-02-08 9:29 ` Cyrill Gorcunov
2022-02-08 16:21 ` Andy Lutomirski
2022-02-08 17:02 ` Cyrill Gorcunov
2022-02-09 2:18 ` Edgecombe, Rick P
2022-02-09 6:43 ` Cyrill Gorcunov
2022-02-09 10:53 ` Mike Rapoport
2022-02-10 2:37 ` Andy Lutomirski
2022-02-10 2:53 ` H.J. Lu
2022-02-10 13:52 ` Willgerodt, Felix
2022-02-11 7:41 ` avagin
2022-02-11 8:04 ` Mike Rapoport
2022-02-28 20:27 ` Mike Rapoport
2022-02-28 20:30 ` Andy Lutomirski
2022-02-28 21:30 ` Mike Rapoport
2022-02-28 22:55 ` Andy Lutomirski
2022-03-03 19:40 ` Mike Rapoport
2022-03-03 23:00 ` Andy Lutomirski
2022-03-04 1:30 ` Edgecombe, Rick P
2022-03-04 19:13 ` Andy Lutomirski
2022-03-07 18:56 ` Mike Rapoport
2022-03-07 19:07 ` H.J. Lu
2022-05-31 11:59 ` Mike Rapoport
2022-05-31 16:25 ` Edgecombe, Rick P
2022-05-31 16:36 ` Mike Rapoport
2022-05-31 17:34 ` Edgecombe, Rick P
2022-05-31 18:00 ` H.J. Lu
2022-06-01 17:27 ` Edgecombe, Rick P
2022-06-01 19:27 ` H.J. Lu
2022-06-01 8:06 ` Mike Rapoport
2022-06-01 17:24 ` Edgecombe, Rick P
2022-06-09 18:04 ` Mike Rapoport
2022-03-07 22:21 ` David Laight
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=959707bff94b3a54f05cfcfc09fa809f08152807.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=bsingharora@gmail.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=dave.martin@arm.com \
--cc=eranian@google.com \
--cc=esyr@redhat.com \
--cc=fweimer@redhat.com \
--cc=gorcunov@gmail.com \
--cc=hjl.tools@gmail.com \
--cc=hpa@zytor.com \
--cc=jannh@google.com \
--cc=joao.moreira@intel.com \
--cc=john.allen@amd.com \
--cc=kcc@google.com \
--cc=keescook@chromium.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mike.kravetz@oracle.com \
--cc=mingo@redhat.com \
--cc=nadav.amit@gmail.com \
--cc=oleg@redhat.com \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=ravi.v.shankar@intel.com \
--cc=rdunlap@infradead.org \
--cc=tglx@linutronix.de \
--cc=weijiang.yang@intel.com \
--cc=x86@kernel.org \
--cc=yu-cheng.yu@intel.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).