From: Christian Brauner <brauner@kernel.org>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "jannh@google.com" <jannh@google.com>,
"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 09:49:10 +0100 [thread overview]
Message-ID: <20220215084910.ldsbhyizssvxvpz6@wittgenstein> (raw)
In-Reply-To: <959707bff94b3a54f05cfcfc09fa809f08152807.camel@intel.com>
On Tue, Feb 15, 2022 at 01:22:04AM +0000, Edgecombe, Rick P wrote:
> 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.
I'm honestly not sure it makes things that much better but I don't feel
strongly about it either.
>
> But copy_thread() has a ton of arch specific implementations. So they
> would all need to be updated to do this.
When struct kernel_clone_args was introduced I also removed the
copy_thread_tls() and copy_thread() split. So now we're only left with
copy_thread(). That already allowed us to get rid of some arch-specific
code. I didn't go further in trying to unify more arch-specific code. It
might be worth it but I didn't come to a clear conclusion.
>
> 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 8:49 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
2022-02-15 8:49 ` Christian Brauner [this message]
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=20220215084910.ldsbhyizssvxvpz6@wittgenstein \
--to=brauner@kernel.org \
--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=rick.p.edgecombe@intel.com \
--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