From: Steven Rostedt <rostedt@goodmis.org>
To: Linus Torvalds <torvalds@linux-foundation.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>,
Masami Hiramatsu <mhiramat@kernel.org>
Subject: Re: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions
Date: Tue, 7 May 2019 11:12:27 -0400 [thread overview]
Message-ID: <20190507111227.1d4268d7@gandalf.local.home> (raw)
In-Reply-To: <CAHk-=wg2_okyU8mpkGCUrudgfg8YmNetSD8=scNbOkN+imqZdQ@mail.gmail.com>
On Tue, 7 May 2019 07:54:53 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> And honestly, I absolutely despise PeterZ's patch. The notion that we
> should suddenly say that "oh, the i386 kernel stack is odd" after 28
> years of having that standard i386 stack is just crazy. And this:
>
> arch/x86/entry/entry_32.S | 136 ++++++++++++++++++++++++++++-------
> ...
> 12 files changed, 323 insertions(+), 140 deletions(-)
>
>
> vs this:
>
> arch/x86/entry/entry_32.S | 7 +++-
> ...
> 6 files changed, 120 insertions(+), 13 deletions(-)
>
> is still pretty damn conclusive. Not to mention that the simple
> approach had a truly mindbogglingly simple solution with no actual
> subtle changes anywhere else.
>
> So I still claim that we should do my patch. Because it is SIMPLE.
> It's straightforward, and I can explain every single line in it. Even
> if I spent *way* too long until I realized that the "trivial"
> memmove() wasn't so trivial.
Yes, band-aids are usually simpler than a proper fix. We have 28 years
of hacks built on hacks. There's a lot of hacks in the C code to handle
the differences between the crappy way x86_32 does pt_regs and the
proper way x86_64 does them.
If the goal was just to add another band-aid to this, we now have one
more subtle work around caused by two different methods being handled
by a single code base.
I don't look at Peter's patch and think "this is the solution for int3
emulate calls". I see Peter's patch as "Thanks God, we are finally
getting rid of the cause of all theses work around hacks all over the
place! and oh by the way, we can easily implement int3 call emulation
because of it".
To implement your way, we need to change how the int3 handler works.
It will be the only exception handler having to return regs, otherwise
it will crash.
Sure, it's an easily solution for the one off change of emulating
calls, but it's just another complex work around that nobody is going
to understand in 5 years.
-- Steve
WARNING: multiple messages have this Message-ID (diff)
From: rostedt at goodmis.org (Steven Rostedt)
Subject: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions
Date: Tue, 7 May 2019 11:12:27 -0400 [thread overview]
Message-ID: <20190507111227.1d4268d7@gandalf.local.home> (raw)
In-Reply-To: <CAHk-=wg2_okyU8mpkGCUrudgfg8YmNetSD8=scNbOkN+imqZdQ@mail.gmail.com>
On Tue, 7 May 2019 07:54:53 -0700
Linus Torvalds <torvalds at linux-foundation.org> wrote:
> And honestly, I absolutely despise PeterZ's patch. The notion that we
> should suddenly say that "oh, the i386 kernel stack is odd" after 28
> years of having that standard i386 stack is just crazy. And this:
>
> arch/x86/entry/entry_32.S | 136 ++++++++++++++++++++++++++++-------
> ...
> 12 files changed, 323 insertions(+), 140 deletions(-)
>
>
> vs this:
>
> arch/x86/entry/entry_32.S | 7 +++-
> ...
> 6 files changed, 120 insertions(+), 13 deletions(-)
>
> is still pretty damn conclusive. Not to mention that the simple
> approach had a truly mindbogglingly simple solution with no actual
> subtle changes anywhere else.
>
> So I still claim that we should do my patch. Because it is SIMPLE.
> It's straightforward, and I can explain every single line in it. Even
> if I spent *way* too long until I realized that the "trivial"
> memmove() wasn't so trivial.
Yes, band-aids are usually simpler than a proper fix. We have 28 years
of hacks built on hacks. There's a lot of hacks in the C code to handle
the differences between the crappy way x86_32 does pt_regs and the
proper way x86_64 does them.
If the goal was just to add another band-aid to this, we now have one
more subtle work around caused by two different methods being handled
by a single code base.
I don't look at Peter's patch and think "this is the solution for int3
emulate calls". I see Peter's patch as "Thanks God, we are finally
getting rid of the cause of all theses work around hacks all over the
place! and oh by the way, we can easily implement int3 call emulation
because of it".
To implement your way, we need to change how the int3 handler works.
It will be the only exception handler having to return regs, otherwise
it will crash.
Sure, it's an easily solution for the one off change of emulating
calls, but it's just another complex work around that nobody is going
to understand in 5 years.
-- Steve
WARNING: multiple messages have this Message-ID (diff)
From: rostedt@goodmis.org (Steven Rostedt)
Subject: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions
Date: Tue, 7 May 2019 11:12:27 -0400 [thread overview]
Message-ID: <20190507111227.1d4268d7@gandalf.local.home> (raw)
Message-ID: <20190507151227.-L5mL_ihZ56kUbZlkNFqQoFfzfDH33NQ2uYqZmH48CQ@z> (raw)
In-Reply-To: <CAHk-=wg2_okyU8mpkGCUrudgfg8YmNetSD8=scNbOkN+imqZdQ@mail.gmail.com>
On Tue, 7 May 2019 07:54:53 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> And honestly, I absolutely despise PeterZ's patch. The notion that we
> should suddenly say that "oh, the i386 kernel stack is odd" after 28
> years of having that standard i386 stack is just crazy. And this:
>
> arch/x86/entry/entry_32.S | 136 ++++++++++++++++++++++++++++-------
> ...
> 12 files changed, 323 insertions(+), 140 deletions(-)
>
>
> vs this:
>
> arch/x86/entry/entry_32.S | 7 +++-
> ...
> 6 files changed, 120 insertions(+), 13 deletions(-)
>
> is still pretty damn conclusive. Not to mention that the simple
> approach had a truly mindbogglingly simple solution with no actual
> subtle changes anywhere else.
>
> So I still claim that we should do my patch. Because it is SIMPLE.
> It's straightforward, and I can explain every single line in it. Even
> if I spent *way* too long until I realized that the "trivial"
> memmove() wasn't so trivial.
Yes, band-aids are usually simpler than a proper fix. We have 28 years
of hacks built on hacks. There's a lot of hacks in the C code to handle
the differences between the crappy way x86_32 does pt_regs and the
proper way x86_64 does them.
If the goal was just to add another band-aid to this, we now have one
more subtle work around caused by two different methods being handled
by a single code base.
I don't look at Peter's patch and think "this is the solution for int3
emulate calls". I see Peter's patch as "Thanks God, we are finally
getting rid of the cause of all theses work around hacks all over the
place! and oh by the way, we can easily implement int3 call emulation
because of it".
To implement your way, we need to change how the int3 handler works.
It will be the only exception handler having to return regs, otherwise
it will crash.
Sure, it's an easily solution for the one off change of emulating
calls, but it's just another complex work around that nobody is going
to understand in 5 years.
-- Steve
next prev parent reply other threads:[~2019-05-07 15:12 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
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 [this message]
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=20190507111227.1d4268d7@gandalf.local.home \
--to=rostedt@goodmis.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=mhiramat@kernel.org \
--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=shuah@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=torvalds@linux-foundation.org \
--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.