From: Linus Torvalds <torvalds@linux-foundation.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Andy Lutomirski <luto@amacapital.net>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>,
Nicolai Stange <nstange@suse.de>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
"the arch/x86 maintainers" <x86@kernel.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
Petr Mladek <pmladek@suse.com>,
Joe Lawrence <joe.lawrence@redhat.com>,
Shuah Khan <shuah@kernel.org>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Mimi Zohar <zohar@linux.ibm.com>, Juergen Gross <jgross@suse.com>,
Nick Desaulniers <ndesaulniers@google.com>,
Nayna Jain <nayna@linux.ibm.com>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Joerg Roedel <jroedel@suse.de>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
stable <stable@vger.kernel.org>
Subject: Re: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions
Date: Mon, 6 May 2019 13:42:12 -0700 [thread overview]
Message-ID: <CAHk-=wi5KBWUOvM94aTOPnoJ5L_aQG=vgLQ4SxxZDeQD0pF2tQ@mail.gmail.com> (raw)
In-Reply-To: <20190506162915.380993f9@gandalf.local.home>
On Mon, May 6, 2019 at 1:29 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> Because that call to ftrace_stub is also dynamic.
You're missing the point.
We are rewriting a single "cal" instruction to point to something.
The "int3" emulation should call THE SAME THING.
Right now it doesn't.
> Part of the code will change it to call the function needed directly.
>
> struct ftrace_ops my_ops {
> .func = my_handler
> };
>
> register_ftrace_function(&my_ops);
>
> Will change "call ftrace_stub" into "call my_handler"
But that's not what you're actually *doing*.
Instead, you're now _emulating_ calling ftrace_regs_caller, which will
call that ftrace_stub, which in turn will try to update the call site.
But that's insane. It's insane because
- it's not even what your call rewriting is doing Why aren't you just
doing the emulation using the *SAME* target that you're rewriting the
actual call instruction with?
- even if ftrace_regs_caller ends up being that same function, you'd
be better off just passing the "struct pt_regs" that you *ALREADY
HAVE* directly to ftrace_stub in the int3 handler, rather than create
*another* pt_regs stack
See? In that second case, why don't you just use "int3_emulate_call()"
to do the reguired 'struct pt_regs' updates, and then call
ftrace_stub() *with* that fixed-up pt_regs thing?
In other words, I think you should always do "int3_emulate_call()"
with the *exact* same address that the instruction you are rewriting
is using. There's no "three different cases". The only possible cases
are "am I rewriting a jump" or "am I rewriting a call".
There is no "am I rewriting a call to one address, and then emulating
it with a call to another address" case that makes sense.
What *can* make sense is "Oh, I'm emulating a call, but I know that
call will be rewritten, so let me emulate the call and then
short-circuit the emulation immediately".
But that is not what the ftrace code is doing. The ftrace code is
doing something odd and insane.
And no, your "explanation" makes no sense. Because it doesn't actually
touch on the fundamental insanity.
Linus
WARNING: multiple messages have this Message-ID (diff)
From: torvalds at linux-foundation.org (Linus Torvalds)
Subject: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions
Date: Mon, 6 May 2019 13:42:12 -0700 [thread overview]
Message-ID: <CAHk-=wi5KBWUOvM94aTOPnoJ5L_aQG=vgLQ4SxxZDeQD0pF2tQ@mail.gmail.com> (raw)
In-Reply-To: <20190506162915.380993f9@gandalf.local.home>
On Mon, May 6, 2019 at 1:29 PM Steven Rostedt <rostedt at goodmis.org> wrote:
>
> Because that call to ftrace_stub is also dynamic.
You're missing the point.
We are rewriting a single "cal" instruction to point to something.
The "int3" emulation should call THE SAME THING.
Right now it doesn't.
> Part of the code will change it to call the function needed directly.
>
> struct ftrace_ops my_ops {
> .func = my_handler
> };
>
> register_ftrace_function(&my_ops);
>
> Will change "call ftrace_stub" into "call my_handler"
But that's not what you're actually *doing*.
Instead, you're now _emulating_ calling ftrace_regs_caller, which will
call that ftrace_stub, which in turn will try to update the call site.
But that's insane. It's insane because
- it's not even what your call rewriting is doing Why aren't you just
doing the emulation using the *SAME* target that you're rewriting the
actual call instruction with?
- even if ftrace_regs_caller ends up being that same function, you'd
be better off just passing the "struct pt_regs" that you *ALREADY
HAVE* directly to ftrace_stub in the int3 handler, rather than create
*another* pt_regs stack
See? In that second case, why don't you just use "int3_emulate_call()"
to do the reguired 'struct pt_regs' updates, and then call
ftrace_stub() *with* that fixed-up pt_regs thing?
In other words, I think you should always do "int3_emulate_call()"
with the *exact* same address that the instruction you are rewriting
is using. There's no "three different cases". The only possible cases
are "am I rewriting a jump" or "am I rewriting a call".
There is no "am I rewriting a call to one address, and then emulating
it with a call to another address" case that makes sense.
What *can* make sense is "Oh, I'm emulating a call, but I know that
call will be rewritten, so let me emulate the call and then
short-circuit the emulation immediately".
But that is not what the ftrace code is doing. The ftrace code is
doing something odd and insane.
And no, your "explanation" makes no sense. Because it doesn't actually
touch on the fundamental insanity.
Linus
WARNING: multiple messages have this Message-ID (diff)
From: torvalds@linux-foundation.org (Linus Torvalds)
Subject: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions
Date: Mon, 6 May 2019 13:42:12 -0700 [thread overview]
Message-ID: <CAHk-=wi5KBWUOvM94aTOPnoJ5L_aQG=vgLQ4SxxZDeQD0pF2tQ@mail.gmail.com> (raw)
Message-ID: <20190506204212.VY1jPTq4GdRSiI-48NpArpXJ7grKFGWrV_rcXPMhT_Y@z> (raw)
In-Reply-To: <20190506162915.380993f9@gandalf.local.home>
On Mon, May 6, 2019@1:29 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> Because that call to ftrace_stub is also dynamic.
You're missing the point.
We are rewriting a single "cal" instruction to point to something.
The "int3" emulation should call THE SAME THING.
Right now it doesn't.
> Part of the code will change it to call the function needed directly.
>
> struct ftrace_ops my_ops {
> .func = my_handler
> };
>
> register_ftrace_function(&my_ops);
>
> Will change "call ftrace_stub" into "call my_handler"
But that's not what you're actually *doing*.
Instead, you're now _emulating_ calling ftrace_regs_caller, which will
call that ftrace_stub, which in turn will try to update the call site.
But that's insane. It's insane because
- it's not even what your call rewriting is doing Why aren't you just
doing the emulation using the *SAME* target that you're rewriting the
actual call instruction with?
- even if ftrace_regs_caller ends up being that same function, you'd
be better off just passing the "struct pt_regs" that you *ALREADY
HAVE* directly to ftrace_stub in the int3 handler, rather than create
*another* pt_regs stack
See? In that second case, why don't you just use "int3_emulate_call()"
to do the reguired 'struct pt_regs' updates, and then call
ftrace_stub() *with* that fixed-up pt_regs thing?
In other words, I think you should always do "int3_emulate_call()"
with the *exact* same address that the instruction you are rewriting
is using. There's no "three different cases". The only possible cases
are "am I rewriting a jump" or "am I rewriting a call".
There is no "am I rewriting a call to one address, and then emulating
it with a call to another address" case that makes sense.
What *can* make sense is "Oh, I'm emulating a call, but I know that
call will be rewritten, so let me emulate the call and then
short-circuit the emulation immediately".
But that is not what the ftrace code is doing. The ftrace code is
doing something odd and insane.
And no, your "explanation" makes no sense. Because it doesn't actually
touch on the fundamental insanity.
Linus
next prev parent reply other threads:[~2019-05-06 20:42 UTC|newest]
Thread overview: 307+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-01 20:28 [RFC][PATCH 0/2] ftrace/x86: Allow for breakpoint handlers to emulate call functions Steven Rostedt
2019-05-01 20:28 ` [RFC][PATCH 1/2] x86: Allow breakpoints " Steven Rostedt
2019-05-01 20:28 ` Steven Rostedt
2019-05-01 20:28 ` rostedt
2019-05-02 3:24 ` Steven Rostedt
2019-05-02 3:24 ` Steven Rostedt
2019-05-02 3:24 ` rostedt
2019-05-02 16:21 ` Peter Zijlstra
2019-05-02 16:21 ` Peter Zijlstra
2019-05-02 16:21 ` peterz
2019-05-02 16:29 ` Peter Zijlstra
2019-05-02 16:29 ` Peter Zijlstra
2019-05-02 16:29 ` peterz
2019-05-02 18:02 ` Linus Torvalds
2019-05-02 18:02 ` Linus Torvalds
2019-05-02 18:02 ` torvalds
2019-05-02 18:18 ` Peter Zijlstra
2019-05-02 18:18 ` Peter Zijlstra
2019-05-02 18:18 ` peterz
2019-05-02 18:30 ` Peter Zijlstra
2019-05-02 18:30 ` Peter Zijlstra
2019-05-02 18:30 ` peterz
2019-05-02 18:43 ` Linus Torvalds
2019-05-02 18:43 ` Linus Torvalds
2019-05-02 18:43 ` torvalds
2019-05-02 19:28 ` Jiri Kosina
2019-05-02 19:28 ` Jiri Kosina
2019-05-02 19:28 ` jikos
2019-05-02 20:25 ` Andy Lutomirski
2019-05-02 20:25 ` Andy Lutomirski
2019-05-02 20:25 ` luto
2019-05-02 20:21 ` Peter Zijlstra
2019-05-02 20:21 ` Peter Zijlstra
2019-05-02 20:21 ` peterz
2019-05-02 20:49 ` Linus Torvalds
2019-05-02 20:49 ` Linus Torvalds
2019-05-02 20:49 ` torvalds
2019-05-02 21:32 ` Peter Zijlstra
2019-05-02 21:32 ` Peter Zijlstra
2019-05-02 21:32 ` peterz
2019-05-03 19:24 ` Steven Rostedt
2019-05-03 19:24 ` Steven Rostedt
2019-05-03 19:24 ` rostedt
2019-05-03 21:46 ` Linus Torvalds
2019-05-03 21:46 ` Linus Torvalds
2019-05-03 21:46 ` torvalds
2019-05-03 22:49 ` Steven Rostedt
2019-05-03 22:49 ` Steven Rostedt
2019-05-03 22:49 ` rostedt
2019-05-03 23:07 ` Linus Torvalds
2019-05-03 23:07 ` Linus Torvalds
2019-05-03 23:07 ` torvalds
2019-05-04 4:17 ` Steven Rostedt
2019-05-04 4:17 ` Steven Rostedt
2019-05-04 4:17 ` rostedt
[not found] ` <CAHk-=wiuSFbv_rELND-BLWcP0GSZ0yF=xOAEcf61GE3bU9d=yg@mail.gmail.com>
2019-05-04 18:59 ` Linus Torvalds
2019-05-04 18:59 ` Linus Torvalds
2019-05-04 18:59 ` torvalds
2019-05-04 20:12 ` Andy Lutomirski
2019-05-04 20:12 ` Andy Lutomirski
2019-05-04 20:12 ` luto
2019-05-04 20:28 ` Linus Torvalds
2019-05-04 20:28 ` Linus Torvalds
2019-05-04 20:28 ` torvalds
2019-05-04 20:36 ` Linus Torvalds
2019-05-04 20:36 ` Linus Torvalds
2019-05-04 20:36 ` torvalds
2019-05-03 22:55 ` Andy Lutomirski
2019-05-03 22:55 ` Andy Lutomirski
2019-05-03 22:55 ` luto
2019-05-03 23:16 ` Linus Torvalds
2019-05-03 23:16 ` Linus Torvalds
2019-05-03 23:16 ` torvalds
2019-05-03 23:32 ` Andy Lutomirski
2019-05-03 23:32 ` Andy Lutomirski
2019-05-03 23:32 ` luto
2019-05-02 22:52 ` Steven Rostedt
2019-05-02 22:52 ` Steven Rostedt
2019-05-02 22:52 ` rostedt
2019-05-02 23:31 ` Steven Rostedt
2019-05-02 23:31 ` Steven Rostedt
2019-05-02 23:31 ` rostedt
2019-05-02 23:50 ` Steven Rostedt
2019-05-02 23:50 ` Steven Rostedt
2019-05-02 23:50 ` rostedt
2019-05-03 1:51 ` [RFC][PATCH 1/2 v2] " Steven Rostedt
2019-05-03 1:51 ` Steven Rostedt
2019-05-03 1:51 ` rostedt
2019-05-03 9:29 ` [RFC][PATCH 1/2] " Peter Zijlstra
2019-05-03 9:29 ` Peter Zijlstra
2019-05-03 9:29 ` peterz
2019-05-03 13:22 ` Steven Rostedt
2019-05-03 13:22 ` Steven Rostedt
2019-05-03 13:22 ` rostedt
2019-05-03 16:20 ` Andy Lutomirski
2019-05-03 16:20 ` Andy Lutomirski
2019-05-03 16:20 ` luto
2019-05-03 16:31 ` Steven Rostedt
2019-05-03 16:31 ` Steven Rostedt
2019-05-03 16:31 ` rostedt
2019-05-03 16:35 ` Peter Zijlstra
2019-05-03 16:35 ` Peter Zijlstra
2019-05-03 16:35 ` peterz
2019-05-03 16:44 ` Andy Lutomirski
2019-05-03 16:44 ` Andy Lutomirski
2019-05-03 16:44 ` luto
2019-05-03 16:49 ` Steven Rostedt
2019-05-03 16:49 ` Steven Rostedt
2019-05-03 16:49 ` rostedt
2019-05-03 16:32 ` Peter Zijlstra
2019-05-03 16:32 ` Peter Zijlstra
2019-05-03 16:32 ` peterz
2019-05-03 18:57 ` Linus Torvalds
2019-05-03 18:57 ` Linus Torvalds
2019-05-03 18:57 ` torvalds
2019-05-06 8:19 ` Peter Zijlstra
2019-05-06 8:19 ` Peter Zijlstra
2019-05-06 8:19 ` peterz
2019-05-06 13:56 ` Steven Rostedt
2019-05-06 13:56 ` Steven Rostedt
2019-05-06 13:56 ` rostedt
2019-05-06 16:17 ` Linus Torvalds
2019-05-06 16:17 ` Linus Torvalds
2019-05-06 16:17 ` torvalds
2019-05-06 16:19 ` Linus Torvalds
2019-05-06 16:19 ` Linus Torvalds
2019-05-06 16:19 ` torvalds
2019-05-06 17:06 ` Steven Rostedt
2019-05-06 17:06 ` Steven Rostedt
2019-05-06 17:06 ` rostedt
2019-05-06 18:06 ` Linus Torvalds
2019-05-06 18:06 ` Linus Torvalds
2019-05-06 18:06 ` torvalds
2019-05-06 18:57 ` Steven Rostedt
2019-05-06 18:57 ` Steven Rostedt
2019-05-06 18:57 ` rostedt
2019-05-06 19:46 ` Linus Torvalds
2019-05-06 19:46 ` Linus Torvalds
2019-05-06 19:46 ` torvalds
2019-05-06 20:29 ` Steven Rostedt
2019-05-06 20:29 ` Steven Rostedt
2019-05-06 20:29 ` rostedt
2019-05-06 20:42 ` Linus Torvalds [this message]
2019-05-06 20:42 ` Linus Torvalds
2019-05-06 20:42 ` torvalds
2019-05-06 20:44 ` Linus Torvalds
2019-05-06 20:44 ` Linus Torvalds
2019-05-06 20:44 ` torvalds
2019-05-06 21:45 ` Steven Rostedt
2019-05-06 21:45 ` Steven Rostedt
2019-05-06 21:45 ` rostedt
2019-05-06 22:06 ` Linus Torvalds
2019-05-06 22:06 ` Linus Torvalds
2019-05-06 22:06 ` torvalds
2019-05-06 22:31 ` Linus Torvalds
2019-05-06 22:31 ` Linus Torvalds
2019-05-06 22:31 ` torvalds
2019-05-07 0:10 ` Steven Rostedt
2019-05-07 0:10 ` Steven Rostedt
2019-05-07 0:10 ` rostedt
2019-05-07 1:06 ` Linus Torvalds
2019-05-07 1:06 ` Linus Torvalds
2019-05-07 1:06 ` torvalds
2019-05-07 1:04 ` Steven Rostedt
2019-05-07 1:04 ` Steven Rostedt
2019-05-07 1:04 ` rostedt
2019-05-07 1:34 ` Steven Rostedt
2019-05-07 1:34 ` Steven Rostedt
2019-05-07 1:34 ` rostedt
2019-05-07 1:34 ` Linus Torvalds
2019-05-07 1:34 ` Linus Torvalds
2019-05-07 1:34 ` torvalds
2019-05-07 1:53 ` Steven Rostedt
2019-05-07 1:53 ` Steven Rostedt
2019-05-07 1:53 ` rostedt
2019-05-07 2:22 ` Linus Torvalds
2019-05-07 2:22 ` Linus Torvalds
2019-05-07 2:22 ` torvalds
2019-05-07 2:58 ` Steven Rostedt
2019-05-07 2:58 ` Steven Rostedt
2019-05-07 2:58 ` rostedt
2019-05-07 3:05 ` Linus Torvalds
2019-05-07 3:05 ` Linus Torvalds
2019-05-07 3:05 ` torvalds
2019-05-07 3:21 ` Steven Rostedt
2019-05-07 3:21 ` Steven Rostedt
2019-05-07 3:21 ` rostedt
2019-05-07 3:28 ` Linus Torvalds
2019-05-07 3:28 ` Linus Torvalds
2019-05-07 3:28 ` torvalds
2019-05-07 14:54 ` Linus Torvalds
2019-05-07 14:54 ` Linus Torvalds
2019-05-07 14:54 ` torvalds
2019-05-07 15:12 ` Steven Rostedt
2019-05-07 15:12 ` Steven Rostedt
2019-05-07 15:12 ` rostedt
2019-05-07 15:25 ` Steven Rostedt
2019-05-07 15:25 ` Steven Rostedt
2019-05-07 15:25 ` rostedt
2019-05-07 16:25 ` Steven Rostedt
2019-05-07 16:25 ` Steven Rostedt
2019-05-07 16:25 ` rostedt
2019-05-07 15:31 ` Linus Torvalds
2019-05-07 15:31 ` Linus Torvalds
2019-05-07 15:31 ` torvalds
2019-05-07 15:45 ` Steven Rostedt
2019-05-07 15:45 ` Steven Rostedt
2019-05-07 15:45 ` rostedt
2019-05-07 16:34 ` Peter Zijlstra
2019-05-07 16:34 ` Peter Zijlstra
2019-05-07 16:34 ` peterz
2019-05-07 17:08 ` Linus Torvalds
2019-05-07 17:08 ` Linus Torvalds
2019-05-07 17:08 ` torvalds
2019-05-07 17:21 ` Josh Poimboeuf
2019-05-07 17:21 ` Josh Poimboeuf
2019-05-07 17:21 ` jpoimboe
2019-05-07 21:24 ` Steven Rostedt
2019-05-07 21:24 ` Steven Rostedt
2019-05-07 21:24 ` rostedt
2019-05-08 4:50 ` Linus Torvalds
2019-05-08 4:50 ` Linus Torvalds
2019-05-08 4:50 ` torvalds
2019-05-08 16:37 ` Steven Rostedt
2019-05-08 16:37 ` Steven Rostedt
2019-05-08 16:37 ` rostedt
2019-05-07 17:38 ` Peter Zijlstra
2019-05-07 17:38 ` Peter Zijlstra
2019-05-07 17:38 ` peterz
2019-05-07 9:51 ` Peter Zijlstra
2019-05-07 9:51 ` Peter Zijlstra
2019-05-07 9:51 ` peterz
2019-05-07 14:48 ` Andy Lutomirski
2019-05-07 14:48 ` Andy Lutomirski
2019-05-07 14:48 ` luto
2019-05-07 14:57 ` Linus Torvalds
2019-05-07 14:57 ` Linus Torvalds
2019-05-07 14:57 ` torvalds
2019-05-07 14:13 ` Masami Hiramatsu
2019-05-07 14:13 ` Masami Hiramatsu
2019-05-07 14:13 ` mhiramat
2019-05-07 17:15 ` Masami Hiramatsu
2019-05-07 17:15 ` Masami Hiramatsu
2019-05-07 17:15 ` mhiramat
2019-05-06 14:22 ` Peter Zijlstra
2019-05-06 14:22 ` Peter Zijlstra
2019-05-06 14:22 ` peterz
2019-05-07 8:57 ` Peter Zijlstra
2019-05-07 8:57 ` Peter Zijlstra
2019-05-07 8:57 ` peterz
2019-05-07 9:18 ` David Laight
2019-05-07 9:18 ` David Laight
2019-05-07 9:18 ` David.Laight
2019-05-07 11:30 ` Peter Zijlstra
2019-05-07 11:30 ` Peter Zijlstra
2019-05-07 11:30 ` peterz
2019-05-07 12:57 ` David Laight
2019-05-07 12:57 ` David Laight
2019-05-07 12:57 ` David.Laight
2019-05-07 13:14 ` Steven Rostedt
2019-05-07 13:14 ` Steven Rostedt
2019-05-07 13:14 ` rostedt
2019-05-07 14:50 ` David Laight
2019-05-07 14:50 ` David Laight
2019-05-07 14:50 ` David.Laight
2019-05-07 14:57 ` Steven Rostedt
2019-05-07 14:57 ` Steven Rostedt
2019-05-07 14:57 ` rostedt
2019-05-07 15:46 ` David Laight
2019-05-07 15:46 ` David Laight
2019-05-07 15:46 ` David.Laight
2019-05-07 13:32 ` Peter Zijlstra
2019-05-07 13:32 ` Peter Zijlstra
2019-05-07 13:32 ` peterz
2019-05-07 9:27 ` Peter Zijlstra
2019-05-07 9:27 ` Peter Zijlstra
2019-05-07 9:27 ` peterz
2019-05-07 12:27 ` Steven Rostedt
2019-05-07 12:27 ` Steven Rostedt
2019-05-07 12:27 ` rostedt
2019-05-07 12:41 ` Peter Zijlstra
2019-05-07 12:41 ` Peter Zijlstra
2019-05-07 12:41 ` peterz
2019-05-07 12:54 ` Steven Rostedt
2019-05-07 12:54 ` Steven Rostedt
2019-05-07 12:54 ` rostedt
2019-05-07 17:22 ` Masami Hiramatsu
2019-05-07 17:22 ` Masami Hiramatsu
2019-05-07 17:22 ` masami.hiramatsu
2019-05-07 14:28 ` Peter Zijlstra
2019-05-07 14:28 ` Peter Zijlstra
2019-05-07 14:28 ` peterz
2019-05-02 20:48 ` Steven Rostedt
2019-05-02 20:48 ` Steven Rostedt
2019-05-02 20:48 ` rostedt
2019-05-06 15:14 ` Josh Poimboeuf
2019-05-06 15:14 ` Josh Poimboeuf
2019-05-06 15:14 ` jpoimboe
2019-05-01 20:28 ` [RFC][PATCH 2/2] ftrace/x86: Emulate call function while updating in breakpoint handler Steven Rostedt
2019-05-01 20:28 ` Steven Rostedt
2019-05-01 20:28 ` rostedt
2019-05-03 10:22 ` [RFC][PATCH 1.5/2] x86: Add int3_emulate_call() selftest Peter Zijlstra
2019-05-03 10:22 ` Peter Zijlstra
2019-05-03 10:22 ` peterz
2019-05-03 18:46 ` Steven Rostedt
2019-05-03 18:46 ` Steven Rostedt
2019-05-03 18:46 ` rostedt
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='CAHk-=wi5KBWUOvM94aTOPnoJ5L_aQG=vgLQ4SxxZDeQD0pF2tQ@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@redhat.com \
--cc=jroedel@suse.de \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=mbenes@suse.cz \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=nayna@linux.ibm.com \
--cc=ndesaulniers@google.com \
--cc=nstange@suse.de \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=shuah@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=x86@kernel.org \
--cc=yamada.masahiro@socionext.com \
--cc=zohar@linux.ibm.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 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.