All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolai Stange <nstange@suse.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	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>,
	Andy Lutomirski <luto@kernel.org>, Joerg Roedel <jroedel@suse.de>,
	linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
	linux-kselftest@vger.kernel.org, Nicolai Stange <nstange@suse.de>
Subject: [PATCH 1/4] x86/thread_info: introduce ->ftrace_int3_stack member
Date: Sat, 27 Apr 2019 12:06:36 +0200	[thread overview]
Message-ID: <20190427100639.15074-2-nstange@suse.de> (raw)
In-Reply-To: <20190427100639.15074-1-nstange@suse.de>

Before actually rewriting an insn, x86' DYNAMIC_FTRACE  implementation
places an int3 breakpoint on it. Currently, ftrace_int3_handler() simply
treats the insn in question as nop and advances %rip past it. An upcoming
patch will improve this by making the int3 trap handler emulate the call
insn. To this end, ftrace_int3_handler() will be made to change its iret
frame's ->ip to some stub which will then mimic the function call in the
original context.

Somehow the trapping ->ip address will have to get communicated from
ftrace_int3_handler() to these stubs though. Note that at any given point
in time, there can be at most four such call insn emulations pending:
namely at most one per "process", "irq", "softirq" and "nmi" context.

Introduce struct ftrace_int3_stack providing four entries for storing
the instruction pointer.

In principle, it could be made per-cpu, but this would require making
ftrace_int3_handler() to return with preemption disabled and to enable it
from those emulation stubs again only after the stack's top entry has been
consumed. I've been told that this would "break a lot of norms" and that
making this stack part of struct thread_info instead would be less fragile.
Follow this advice and add a struct ftrace_int3_stack instance to x86's
struct thread_info. Note that these stacks will get only rarely accessed
(only during ftrace's code modifications) and thus, cache line dirtying
won't have any significant impact on the neighbouring fields.

Initialization will take place implicitly through INIT_THREAD_INFO as per
the rules for missing elements in initializers. The memcpy() in
arch_dup_task_struct() will propagate the initial state properly, because
it's always run in process context and won't ever see a non-zero ->depth
value.

Finally, add the necessary bits to asm-offsets for making struct
ftrace_int3_stack accessible from assembly.

Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Nicolai Stange <nstange@suse.de>
---
 arch/x86/include/asm/thread_info.h | 11 +++++++++++
 arch/x86/kernel/asm-offsets.c      |  8 ++++++++
 2 files changed, 19 insertions(+)

diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h
index e0eccbcb8447..83434a88cfbb 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -56,6 +56,17 @@ struct task_struct;
 struct thread_info {
 	unsigned long		flags;		/* low level flags */
 	u32			status;		/* thread synchronous flags */
+#ifdef CONFIG_DYNAMIC_FTRACE
+	struct ftrace_int3_stack {
+		int depth;
+		/*
+		 * There can be at most one slot in use per context,
+		 * i.e. at most one for "normal", "irq", "softirq" and
+		 * "nmi" each.
+		 */
+		unsigned long slots[4];
+	} ftrace_int3_stack;
+#endif
 };
 
 #define INIT_THREAD_INFO(tsk)			\
diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
index 168543d077d7..ca6ee24a0c6e 100644
--- a/arch/x86/kernel/asm-offsets.c
+++ b/arch/x86/kernel/asm-offsets.c
@@ -105,4 +105,12 @@ static void __used common(void)
 	OFFSET(TSS_sp0, tss_struct, x86_tss.sp0);
 	OFFSET(TSS_sp1, tss_struct, x86_tss.sp1);
 	OFFSET(TSS_sp2, tss_struct, x86_tss.sp2);
+
+#ifdef CONFIG_DYNAMIC_FTRACE
+	BLANK();
+	OFFSET(TASK_TI_ftrace_int3_depth, task_struct,
+	       thread_info.ftrace_int3_stack.depth);
+	OFFSET(TASK_TI_ftrace_int3_slots, task_struct,
+	       thread_info.ftrace_int3_stack.slots);
+#endif
 }
-- 
2.13.7


WARNING: multiple messages have this Message-ID (diff)
From: nstange at suse.de (Nicolai Stange)
Subject: [PATCH 1/4] x86/thread_info: introduce ->ftrace_int3_stack member
Date: Sat, 27 Apr 2019 12:06:36 +0200	[thread overview]
Message-ID: <20190427100639.15074-2-nstange@suse.de> (raw)
In-Reply-To: <20190427100639.15074-1-nstange@suse.de>

Before actually rewriting an insn, x86' DYNAMIC_FTRACE  implementation
places an int3 breakpoint on it. Currently, ftrace_int3_handler() simply
treats the insn in question as nop and advances %rip past it. An upcoming
patch will improve this by making the int3 trap handler emulate the call
insn. To this end, ftrace_int3_handler() will be made to change its iret
frame's ->ip to some stub which will then mimic the function call in the
original context.

Somehow the trapping ->ip address will have to get communicated from
ftrace_int3_handler() to these stubs though. Note that at any given point
in time, there can be at most four such call insn emulations pending:
namely at most one per "process", "irq", "softirq" and "nmi" context.

Introduce struct ftrace_int3_stack providing four entries for storing
the instruction pointer.

In principle, it could be made per-cpu, but this would require making
ftrace_int3_handler() to return with preemption disabled and to enable it
from those emulation stubs again only after the stack's top entry has been
consumed. I've been told that this would "break a lot of norms" and that
making this stack part of struct thread_info instead would be less fragile.
Follow this advice and add a struct ftrace_int3_stack instance to x86's
struct thread_info. Note that these stacks will get only rarely accessed
(only during ftrace's code modifications) and thus, cache line dirtying
won't have any significant impact on the neighbouring fields.

Initialization will take place implicitly through INIT_THREAD_INFO as per
the rules for missing elements in initializers. The memcpy() in
arch_dup_task_struct() will propagate the initial state properly, because
it's always run in process context and won't ever see a non-zero ->depth
value.

Finally, add the necessary bits to asm-offsets for making struct
ftrace_int3_stack accessible from assembly.

Suggested-by: Steven Rostedt <rostedt at goodmis.org>
Signed-off-by: Nicolai Stange <nstange at suse.de>
---
 arch/x86/include/asm/thread_info.h | 11 +++++++++++
 arch/x86/kernel/asm-offsets.c      |  8 ++++++++
 2 files changed, 19 insertions(+)

diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h
index e0eccbcb8447..83434a88cfbb 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -56,6 +56,17 @@ struct task_struct;
 struct thread_info {
 	unsigned long		flags;		/* low level flags */
 	u32			status;		/* thread synchronous flags */
+#ifdef CONFIG_DYNAMIC_FTRACE
+	struct ftrace_int3_stack {
+		int depth;
+		/*
+		 * There can be at most one slot in use per context,
+		 * i.e. at most one for "normal", "irq", "softirq" and
+		 * "nmi" each.
+		 */
+		unsigned long slots[4];
+	} ftrace_int3_stack;
+#endif
 };
 
 #define INIT_THREAD_INFO(tsk)			\
diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
index 168543d077d7..ca6ee24a0c6e 100644
--- a/arch/x86/kernel/asm-offsets.c
+++ b/arch/x86/kernel/asm-offsets.c
@@ -105,4 +105,12 @@ static void __used common(void)
 	OFFSET(TSS_sp0, tss_struct, x86_tss.sp0);
 	OFFSET(TSS_sp1, tss_struct, x86_tss.sp1);
 	OFFSET(TSS_sp2, tss_struct, x86_tss.sp2);
+
+#ifdef CONFIG_DYNAMIC_FTRACE
+	BLANK();
+	OFFSET(TASK_TI_ftrace_int3_depth, task_struct,
+	       thread_info.ftrace_int3_stack.depth);
+	OFFSET(TASK_TI_ftrace_int3_slots, task_struct,
+	       thread_info.ftrace_int3_stack.slots);
+#endif
 }
-- 
2.13.7

WARNING: multiple messages have this Message-ID (diff)
From: nstange@suse.de (Nicolai Stange)
Subject: [PATCH 1/4] x86/thread_info: introduce ->ftrace_int3_stack member
Date: Sat, 27 Apr 2019 12:06:36 +0200	[thread overview]
Message-ID: <20190427100639.15074-2-nstange@suse.de> (raw)
Message-ID: <20190427100636.BhmxbjEa84btDFA8-IXIqAEI3BpRB-NOqQk1uwK2L_k@z> (raw)
In-Reply-To: <20190427100639.15074-1-nstange@suse.de>

Before actually rewriting an insn, x86' DYNAMIC_FTRACE  implementation
places an int3 breakpoint on it. Currently, ftrace_int3_handler() simply
treats the insn in question as nop and advances %rip past it. An upcoming
patch will improve this by making the int3 trap handler emulate the call
insn. To this end, ftrace_int3_handler() will be made to change its iret
frame's ->ip to some stub which will then mimic the function call in the
original context.

Somehow the trapping ->ip address will have to get communicated from
ftrace_int3_handler() to these stubs though. Note that at any given point
in time, there can be at most four such call insn emulations pending:
namely at most one per "process", "irq", "softirq" and "nmi" context.

Introduce struct ftrace_int3_stack providing four entries for storing
the instruction pointer.

In principle, it could be made per-cpu, but this would require making
ftrace_int3_handler() to return with preemption disabled and to enable it
from those emulation stubs again only after the stack's top entry has been
consumed. I've been told that this would "break a lot of norms" and that
making this stack part of struct thread_info instead would be less fragile.
Follow this advice and add a struct ftrace_int3_stack instance to x86's
struct thread_info. Note that these stacks will get only rarely accessed
(only during ftrace's code modifications) and thus, cache line dirtying
won't have any significant impact on the neighbouring fields.

Initialization will take place implicitly through INIT_THREAD_INFO as per
the rules for missing elements in initializers. The memcpy() in
arch_dup_task_struct() will propagate the initial state properly, because
it's always run in process context and won't ever see a non-zero ->depth
value.

Finally, add the necessary bits to asm-offsets for making struct
ftrace_int3_stack accessible from assembly.

Suggested-by: Steven Rostedt <rostedt at goodmis.org>
Signed-off-by: Nicolai Stange <nstange at suse.de>
---
 arch/x86/include/asm/thread_info.h | 11 +++++++++++
 arch/x86/kernel/asm-offsets.c      |  8 ++++++++
 2 files changed, 19 insertions(+)

diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h
index e0eccbcb8447..83434a88cfbb 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -56,6 +56,17 @@ struct task_struct;
 struct thread_info {
 	unsigned long		flags;		/* low level flags */
 	u32			status;		/* thread synchronous flags */
+#ifdef CONFIG_DYNAMIC_FTRACE
+	struct ftrace_int3_stack {
+		int depth;
+		/*
+		 * There can be at most one slot in use per context,
+		 * i.e. at most one for "normal", "irq", "softirq" and
+		 * "nmi" each.
+		 */
+		unsigned long slots[4];
+	} ftrace_int3_stack;
+#endif
 };
 
 #define INIT_THREAD_INFO(tsk)			\
diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
index 168543d077d7..ca6ee24a0c6e 100644
--- a/arch/x86/kernel/asm-offsets.c
+++ b/arch/x86/kernel/asm-offsets.c
@@ -105,4 +105,12 @@ static void __used common(void)
 	OFFSET(TSS_sp0, tss_struct, x86_tss.sp0);
 	OFFSET(TSS_sp1, tss_struct, x86_tss.sp1);
 	OFFSET(TSS_sp2, tss_struct, x86_tss.sp2);
+
+#ifdef CONFIG_DYNAMIC_FTRACE
+	BLANK();
+	OFFSET(TASK_TI_ftrace_int3_depth, task_struct,
+	       thread_info.ftrace_int3_stack.depth);
+	OFFSET(TASK_TI_ftrace_int3_slots, task_struct,
+	       thread_info.ftrace_int3_stack.slots);
+#endif
 }
-- 
2.13.7

  reply	other threads:[~2019-04-27 10:07 UTC|newest]

Thread overview: 192+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-27 10:06 [PATCH 0/4] x86/ftrace: make ftrace_int3_handler() not to skip fops invocation Nicolai Stange
2019-04-27 10:06 ` Nicolai Stange
2019-04-27 10:06 ` nstange
2019-04-27 10:06 ` Nicolai Stange [this message]
2019-04-27 10:06   ` [PATCH 1/4] x86/thread_info: introduce ->ftrace_int3_stack member Nicolai Stange
2019-04-27 10:06   ` nstange
2019-04-28 17:41   ` Andy Lutomirski
2019-04-28 17:41     ` Andy Lutomirski
2019-04-28 17:41     ` luto
2019-04-28 17:51     ` Steven Rostedt
2019-04-28 17:51       ` Steven Rostedt
2019-04-28 17:51       ` rostedt
2019-04-28 18:08       ` Andy Lutomirski
2019-04-28 18:08         ` Andy Lutomirski
2019-04-28 18:08         ` luto
2019-04-28 19:43         ` Steven Rostedt
2019-04-28 19:43           ` Steven Rostedt
2019-04-28 19:43           ` rostedt
2019-04-28 20:56           ` Andy Lutomirski
2019-04-28 20:56             ` Andy Lutomirski
2019-04-28 20:56             ` luto
2019-04-28 21:22       ` Nicolai Stange
2019-04-28 21:22         ` Nicolai Stange
2019-04-28 21:22         ` nstange
2019-04-28 23:27         ` Andy Lutomirski
2019-04-28 23:27           ` Andy Lutomirski
2019-04-28 23:27           ` luto
2019-04-27 10:06 ` [PATCH 2/4] ftrace: drop 'static' qualifier from ftrace_ops_list_func() Nicolai Stange
2019-04-27 10:06   ` Nicolai Stange
2019-04-27 10:06   ` nstange
2019-04-27 10:06 ` [PATCH 3/4] x86/ftrace: make ftrace_int3_handler() not to skip fops invocation Nicolai Stange
2019-04-27 10:06   ` Nicolai Stange
2019-04-27 10:06   ` nstange
2019-04-27 10:26   ` Peter Zijlstra
2019-04-27 10:26     ` Peter Zijlstra
2019-04-27 10:26     ` peterz
2019-04-28 17:38     ` Steven Rostedt
2019-04-28 17:38       ` Steven Rostedt
2019-04-28 17:38       ` rostedt
2019-04-29 18:06       ` Linus Torvalds
2019-04-29 18:06         ` Linus Torvalds
2019-04-29 18:06         ` torvalds
2019-04-29 18:22         ` Linus Torvalds
2019-04-29 18:22           ` Linus Torvalds
2019-04-29 18:22           ` torvalds
2019-04-29 18:42           ` Andy Lutomirski
2019-04-29 18:42             ` Andy Lutomirski
2019-04-29 18:42             ` luto
     [not found]             ` <CAHk-=whtt4K2f0KPtG-4Pykh3FK8UBOjD8jhXCUKB5nWDj_YRA@mail.gmail.com>
2019-04-29 18:56               ` Andy Lutomirski
2019-04-29 18:56                 ` Andy Lutomirski
2019-04-29 18:56                 ` luto
     [not found]                 ` <CAHk-=wgewK4eFhF3=0RNtk1KQjMANFH6oDE=8m=84RExn2gxhw@mail.gmail.com>
     [not found]                   ` <CAHk-=whay7eN6+2gZjY-ybRbkbcqAmgrLwwszzHx8ws3c=S-MA@mail.gmail.com>
2019-04-29 19:24                     ` Andy Lutomirski
2019-04-29 19:24                       ` Andy Lutomirski
2019-04-29 19:24                       ` luto
2019-04-29 20:07                       ` Linus Torvalds
2019-04-29 20:07                         ` Linus Torvalds
2019-04-29 20:07                         ` torvalds
2019-04-30 13:56                         ` Peter Zijlstra
2019-04-30 13:56                           ` Peter Zijlstra
2019-04-30 13:56                           ` peterz
2019-04-30 16:06                           ` Linus Torvalds
2019-04-30 16:06                             ` Linus Torvalds
2019-04-30 16:06                             ` torvalds
2019-04-30 16:33                             ` Andy Lutomirski
2019-04-30 16:33                               ` Andy Lutomirski
2019-04-30 16:33                               ` luto
2019-04-30 17:03                               ` Steven Rostedt
2019-04-30 17:03                                 ` Steven Rostedt
2019-04-30 17:03                                 ` rostedt
2019-04-30 17:20                                 ` Steven Rostedt
2019-04-30 17:20                                   ` Steven Rostedt
2019-04-30 17:20                                   ` rostedt
2019-04-30 17:49                                   ` [RFC][PATCH] ftrace/x86: Emulate call function while updating in breakpoint handler Steven Rostedt
2019-04-30 17:49                                     ` Steven Rostedt
2019-04-30 17:49                                     ` rostedt
2019-04-30 18:33                                     ` Linus Torvalds
2019-04-30 18:33                                       ` Linus Torvalds
2019-04-30 18:33                                       ` torvalds
2019-04-30 19:00                                       ` Steven Rostedt
2019-04-30 19:00                                         ` Steven Rostedt
2019-04-30 19:00                                         ` rostedt
2019-04-30 21:08                                       ` Steven Rostedt
2019-04-30 21:08                                         ` Steven Rostedt
2019-04-30 21:08                                         ` rostedt
2019-05-01 13:11                                       ` Peter Zijlstra
2019-05-01 13:11                                         ` Peter Zijlstra
2019-05-01 13:11                                         ` peterz
2019-05-01 18:58                                         ` Steven Rostedt
2019-05-01 18:58                                           ` Steven Rostedt
2019-05-01 18:58                                           ` rostedt
2019-05-01 19:03                                           ` Peter Zijlstra
2019-05-01 19:03                                             ` Peter Zijlstra
2019-05-01 19:03                                             ` peterz
2019-05-01 19:03                                         ` Linus Torvalds
2019-05-01 19:03                                           ` Linus Torvalds
2019-05-01 19:03                                           ` torvalds
2019-05-01 19:13                                           ` Peter Zijlstra
2019-05-01 19:13                                             ` Peter Zijlstra
2019-05-01 19:13                                             ` peterz
2019-05-01 19:13                                           ` Steven Rostedt
2019-05-01 19:13                                             ` Steven Rostedt
2019-05-01 19:13                                             ` rostedt
2019-05-01 19:33                                             ` Jiri Kosina
2019-05-01 19:33                                               ` Jiri Kosina
2019-05-01 19:33                                               ` jikos
2019-05-01 19:41                                               ` Peter Zijlstra
2019-05-01 19:41                                                 ` Peter Zijlstra
2019-05-01 19:41                                                 ` peterz
2019-04-30 21:53                                     ` [RFC][PATCH v2] " Steven Rostedt
2019-04-30 21:53                                       ` Steven Rostedt
2019-04-30 21:53                                       ` rostedt
2019-05-01  1:35                                       ` Steven Rostedt
2019-05-01  1:35                                         ` Steven Rostedt
2019-05-01  1:35                                         ` rostedt
2019-05-01  1:58                                         ` Linus Torvalds
2019-05-01  1:58                                           ` Linus Torvalds
2019-05-01  1:58                                           ` torvalds
2019-05-01  8:26                                       ` Nicolai Stange
2019-05-01  8:26                                         ` Nicolai Stange
2019-05-01  8:26                                         ` nstange
2019-05-01 13:22                                         ` Steven Rostedt
2019-05-01 13:22                                           ` Steven Rostedt
2019-05-01 13:22                                           ` rostedt
2019-04-29 20:16                   ` [PATCH 3/4] x86/ftrace: make ftrace_int3_handler() not to skip fops invocation Linus Torvalds
2019-04-29 20:16                     ` Linus Torvalds
2019-04-29 20:16                     ` torvalds
2019-04-29 22:08                     ` Sean Christopherson
2019-04-29 22:08                       ` Sean Christopherson
2019-04-29 22:08                       ` sean.j.christopherson
2019-04-29 22:22                       ` Linus Torvalds
2019-04-29 22:22                         ` Linus Torvalds
2019-04-29 22:22                         ` torvalds
2019-04-30  0:08                         ` Sean Christopherson
2019-04-30  0:08                           ` Sean Christopherson
2019-04-30  0:08                           ` sean.j.christopherson
2019-04-30  0:45                           ` Sean Christopherson
2019-04-30  0:45                             ` Sean Christopherson
2019-04-30  0:45                             ` sean.j.christopherson
2019-04-30  2:26                             ` Linus Torvalds
2019-04-30  2:26                               ` Linus Torvalds
2019-04-30  2:26                               ` torvalds
2019-04-30 10:40                               ` Peter Zijlstra
2019-04-30 10:40                                 ` Peter Zijlstra
2019-04-30 10:40                                 ` peterz
2019-04-30 11:17                               ` Jiri Kosina
2019-04-30 11:17                                 ` Jiri Kosina
2019-04-30 11:17                                 ` jikos
2019-04-29 22:06                 ` Linus Torvalds
2019-04-29 22:06                   ` Linus Torvalds
2019-04-29 22:06                   ` torvalds
2019-04-30 11:18                   ` Peter Zijlstra
2019-04-30 11:18                     ` Peter Zijlstra
2019-04-30 11:18                     ` peterz
2019-04-29 18:52         ` Steven Rostedt
2019-04-29 18:52           ` Steven Rostedt
2019-04-29 18:52           ` rostedt
     [not found]           ` <CAHk-=wjm93jLtVxTX4HZs6K4k1Wqh3ujjmapqaYtcibVk_YnzQ@mail.gmail.com>
2019-04-29 19:07             ` Steven Rostedt
2019-04-29 19:07               ` Steven Rostedt
2019-04-29 19:07               ` rostedt
2019-04-29 20:06               ` Linus Torvalds
2019-04-29 20:06                 ` Linus Torvalds
2019-04-29 20:06                 ` torvalds
2019-04-29 20:20                 ` Linus Torvalds
2019-04-29 20:20                   ` Linus Torvalds
2019-04-29 20:20                   ` torvalds
2019-04-29 20:30                 ` Steven Rostedt
2019-04-29 20:30                   ` Steven Rostedt
2019-04-29 20:30                   ` rostedt
2019-04-29 21:38                   ` Linus Torvalds
2019-04-29 21:38                     ` Linus Torvalds
2019-04-29 21:38                     ` torvalds
2019-04-29 22:07                     ` Steven Rostedt
2019-04-29 22:07                       ` Steven Rostedt
2019-04-29 22:07                       ` rostedt
2019-04-30  9:24                       ` Nicolai Stange
2019-04-30  9:24                         ` Nicolai Stange
2019-04-30  9:24                         ` nstange
2019-04-30 10:46           ` Peter Zijlstra
2019-04-30 10:46             ` Peter Zijlstra
2019-04-30 10:46             ` peterz
2019-04-30 13:44             ` Steven Rostedt
2019-04-30 13:44               ` Steven Rostedt
2019-04-30 13:44               ` rostedt
2019-04-30 14:20               ` Peter Zijlstra
2019-04-30 14:20                 ` Peter Zijlstra
2019-04-30 14:20                 ` peterz
2019-04-30 14:36                 ` Steven Rostedt
2019-04-30 14:36                   ` Steven Rostedt
2019-04-30 14:36                   ` rostedt
2019-04-27 10:06 ` [PATCH 4/4] selftests/livepatch: add "ftrace a live patched function" test Nicolai Stange
2019-04-27 10:06   ` Nicolai Stange
2019-04-27 10:06   ` nstange

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=20190427100639.15074-2-nstange@suse.de \
    --to=nstange@suse.de \
    --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=live-patching@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mingo@redhat.com \
    --cc=nayna@linux.ibm.com \
    --cc=ndesaulniers@google.com \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=shuah@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.