All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: "David Long" <dave.long@linaro.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Yang Shi" <yang.shi@linaro.org>,
	"Zi Shen Lim" <zlim.lnx@gmail.com>,
	"Will Deacon" <will.deacon@arm.com>,
	"Andrey Ryabinin" <ryabinin.a.a@gmail.com>,
	"yalin wang" <yalin.wang2010@gmail.com>,
	"Li Bin" <huawei.libin@huawei.com>,
	"Jisheng Zhang" <jszhang@marvell.com>,
	"John Blackwood" <john.blackwood@ccur.com>,
	"Pratyush Anand" <panand@redhat.com>,
	"Huang Shijie" <shijie.huang@arm.com>,
	"Dave P Martin" <Dave.Martin@arm.com>,
	"Petr Mladek" <pmladek@suse.com>,
	"Vladimir Murzin" <Vladimir.Murzin@arm.com>,
	"Steve Capper" <steve.capper@linaro.org>,
	"Suzuki K Poulose" <suzuki.poulose@arm.com>,
	"Marc Zyngier" <marc.zyngier@arm.com>,
	"Mark Brown" <broonie@kernel.org>,
	"Sandeepa Prabhu" <sandeepa.s.prabhu@gmail.com>,
	"William Cohen" <wcohen@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Adam Buchbinder" <adam.buchbinder@gmail.com>,
	linux-arm-kernel@lists.infradead.org,
	"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
	linux-kernel@vger.kernel.org, "James Morse" <james.morse@arm.com>,
	"Masami Hiramatsu" <mhiramat@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Jens Wiklander" <jens.wiklander@linaro.org>,
	"Christoffer Dall" <christoffer.dall@linaro.org>
Subject: Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support
Date: Tue, 26 Jul 2016 17:55:43 +0100	[thread overview]
Message-ID: <20160726165543.GG2423@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <ce78f577-d14a-7b12-c96f-a6ebd8866283@linaro.org>

On Tue, Jul 26, 2016 at 10:50:08AM +0100, Daniel Thompson wrote:
> On 25/07/16 18:13, Catalin Marinas wrote:
> >On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote:
> >>On 07/22/2016 06:16 AM, Catalin Marinas wrote:
> >>>On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
> >>>[...]
> >>>The document states: "Up to MAX_STACK_SIZE bytes are copied". That means
> >>>the arch code could always copy less but never more than MAX_STACK_SIZE.
> >>>What we are proposing is that we should try to guess how much to copy
> >>>based on the FP value (caller's frame) and, if larger than
> >>>MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes
> >>>against the kprobes.txt document but at least it (a) may improve the
> >>>performance slightly by avoiding unnecessary copy and (b) it avoids
> >>>undefined behaviour if we ever encounter a jprobe with arguments passed
> >>>on the stack beyond MAX_STACK_SIZE.
> >>
> >>OK, it sounds like an improvement. I do worry a little about unexpected side
> >>effects.
> >
> >You get more unexpected side effects by not saving/restoring the whole
> >stack. We looked into this on Friday and came to the conclusion that
> >there is no safe way for kprobes to know which arguments passed on the
> >stack should be preserved, at least not with the current API.
> >
> >Basically the AArch64 PCS states that for arguments passed on the stack
> >(e.g. they can't fit in registers), the caller allocates memory for them
> >(on its own stack) and passes the pointer to the callee. Unfortunately,
> >the frame pointer seems to be decremented correspondingly to cover the
> >arguments, so we don't really have a way to tell how much to copy.
> >Copying just the caller's stack frame isn't safe either since a
> >callee/caller receiving such argument on the stack may passed it down to
> >a callee without copying (I couldn't find anything in the PCS stating
> >that this isn't allowed).
> 
> The PCS[1] seems (at least to me) to be pretty clear that "the address of
> the first stacked argument is defined to be the initial value of SP".
> 
> I think it is only the return value (when stacked via the x8 pointer) that
> can be passed through an intermediate function in the way described above.
> Isn't it OK for a jprobe to clobber this memory? The underlying function
> will overwrite whatever the jprobe put there anyway.
> 
> Am I overlooking some additional detail in the PCS?

I'm not sure I fully understand the PCS. I played with some random hacks
to test_kprobes.c (see below) and the address passed for a big struct
didn't look like the bottom of the stack.

diff --git a/kernel/test_kprobes.c b/kernel/test_kprobes.c
index 0dbab6d1acb4..6ed7be02a560 100644
--- a/kernel/test_kprobes.c
+++ b/kernel/test_kprobes.c
@@ -22,14 +22,18 @@
 
 #define div_factor 3
 
+struct dummy {
+	char dummy_array[MAX_STACK_SIZE * 2];
+};
+
 static u32 rand1, preh_val, posth_val, jph_val;
 static int errors, handler_errors, num_tests;
-static u32 (*target)(u32 value);
+static u32 (*target)(u32 value, struct dummy d);
 static u32 (*target2)(u32 value);
 
-static noinline u32 kprobe_target(u32 value)
+static noinline u32 kprobe_target(u32 value, struct dummy d)
 {
-	return (value / div_factor);
+	return (value / div_factor - d.dummy_array[0] + d.dummy_array[1]);
 }
 
 static int kp_pre_handler(struct kprobe *p, struct pt_regs *regs)
@@ -54,9 +58,11 @@ static struct kprobe kp = {
 	.post_handler = kp_post_handler
 };
 
-static int test_kprobe(void)
+static int noinline test_kprobe(void)
 {
 	int ret;
+	static struct dummy dummy;
+	memset(&dummy, 10, sizeof(dummy));
 
 	ret = register_kprobe(&kp);
 	if (ret < 0) {
@@ -64,7 +70,8 @@ static int test_kprobe(void)
 		return ret;
 	}
 
-	ret = target(rand1);
+	ret = target(rand1, dummy);
+	memset(&dummy, 10, sizeof(dummy));
 	unregister_kprobe(&kp);
 
 	if (preh_val == 0) {
@@ -111,6 +118,8 @@ static int test_kprobes(void)
 {
 	int ret;
 	struct kprobe *kps[2] = {&kp, &kp2};
+	struct dummy dummy;
+	memset(&dummy, 10, sizeof(dummy));
 
 	/* addr and flags should be cleard for reusing kprobe. */
 	kp.addr = NULL;
@@ -123,7 +132,7 @@ static int test_kprobes(void)
 
 	preh_val = 0;
 	posth_val = 0;
-	ret = target(rand1);
+	ret = target(rand1, dummy);
 
 	if (preh_val == 0) {
 		pr_err("kprobe pre_handler not called\n");
@@ -154,7 +163,7 @@ static int test_kprobes(void)
 
 }
 
-static u32 j_kprobe_target(u32 value)
+static u32 j_kprobe_target(u32 value, struct dummy d)
 {
 	if (value != rand1) {
 		handler_errors++;
@@ -174,6 +183,8 @@ static struct jprobe jp = {
 static int test_jprobe(void)
 {
 	int ret;
+	struct dummy dummy;
+	memset(&dummy, 10, sizeof(dummy));
 
 	ret = register_jprobe(&jp);
 	if (ret < 0) {
@@ -181,7 +192,7 @@ static int test_jprobe(void)
 		return ret;
 	}
 
-	ret = target(rand1);
+	ret = target(rand1, dummy);
 	unregister_jprobe(&jp);
 	if (jph_val == 0) {
 		pr_err("jprobe handler not called\n");
@@ -200,6 +211,8 @@ static int test_jprobes(void)
 {
 	int ret;
 	struct jprobe *jps[2] = {&jp, &jp2};
+	struct dummy dummy;
+	memset(&dummy, 10, sizeof(dummy));
 
 	/* addr and flags should be cleard for reusing kprobe. */
 	jp.kp.addr = NULL;
@@ -211,7 +224,7 @@ static int test_jprobes(void)
 	}
 
 	jph_val = 0;
-	ret = target(rand1);
+	ret = target(rand1, dummy);
 	if (jph_val == 0) {
 		pr_err("jprobe handler not called\n");
 		handler_errors++;
@@ -262,6 +275,8 @@ static struct kretprobe rp = {
 static int test_kretprobe(void)
 {
 	int ret;
+	struct dummy dummy;
+	memset(&dummy, 10, sizeof(dummy));
 
 	ret = register_kretprobe(&rp);
 	if (ret < 0) {
@@ -269,7 +284,7 @@ static int test_kretprobe(void)
 		return ret;
 	}
 
-	ret = target(rand1);
+	ret = target(rand1, dummy);
 	unregister_kretprobe(&rp);
 	if (krph_val != rand1) {
 		pr_err("kretprobe handler not called\n");
@@ -306,6 +321,8 @@ static int test_kretprobes(void)
 {
 	int ret;
 	struct kretprobe *rps[2] = {&rp, &rp2};
+	struct dummy dummy;
+	memset(&dummy, 10, sizeof(dummy));
 
 	/* addr and flags should be cleard for reusing kprobe. */
 	rp.kp.addr = NULL;
@@ -317,7 +334,7 @@ static int test_kretprobes(void)
 	}
 
 	krph_val = 0;
-	ret = target(rand1);
+	ret = target(rand1, dummy);
 	if (krph_val != rand1) {
 		pr_err("kretprobe handler not called\n");
 		handler_errors++;

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v15 04/10] arm64: Kprobes with single stepping support
Date: Tue, 26 Jul 2016 17:55:43 +0100	[thread overview]
Message-ID: <20160726165543.GG2423@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <ce78f577-d14a-7b12-c96f-a6ebd8866283@linaro.org>

On Tue, Jul 26, 2016 at 10:50:08AM +0100, Daniel Thompson wrote:
> On 25/07/16 18:13, Catalin Marinas wrote:
> >On Fri, Jul 22, 2016 at 11:51:32AM -0400, David Long wrote:
> >>On 07/22/2016 06:16 AM, Catalin Marinas wrote:
> >>>On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
> >>>[...]
> >>>The document states: "Up to MAX_STACK_SIZE bytes are copied". That means
> >>>the arch code could always copy less but never more than MAX_STACK_SIZE.
> >>>What we are proposing is that we should try to guess how much to copy
> >>>based on the FP value (caller's frame) and, if larger than
> >>>MAX_STACK_SIZE, skip the probe hook entirely. I don't think this goes
> >>>against the kprobes.txt document but at least it (a) may improve the
> >>>performance slightly by avoiding unnecessary copy and (b) it avoids
> >>>undefined behaviour if we ever encounter a jprobe with arguments passed
> >>>on the stack beyond MAX_STACK_SIZE.
> >>
> >>OK, it sounds like an improvement. I do worry a little about unexpected side
> >>effects.
> >
> >You get more unexpected side effects by not saving/restoring the whole
> >stack. We looked into this on Friday and came to the conclusion that
> >there is no safe way for kprobes to know which arguments passed on the
> >stack should be preserved, at least not with the current API.
> >
> >Basically the AArch64 PCS states that for arguments passed on the stack
> >(e.g. they can't fit in registers), the caller allocates memory for them
> >(on its own stack) and passes the pointer to the callee. Unfortunately,
> >the frame pointer seems to be decremented correspondingly to cover the
> >arguments, so we don't really have a way to tell how much to copy.
> >Copying just the caller's stack frame isn't safe either since a
> >callee/caller receiving such argument on the stack may passed it down to
> >a callee without copying (I couldn't find anything in the PCS stating
> >that this isn't allowed).
> 
> The PCS[1] seems (at least to me) to be pretty clear that "the address of
> the first stacked argument is defined to be the initial value of SP".
> 
> I think it is only the return value (when stacked via the x8 pointer) that
> can be passed through an intermediate function in the way described above.
> Isn't it OK for a jprobe to clobber this memory? The underlying function
> will overwrite whatever the jprobe put there anyway.
> 
> Am I overlooking some additional detail in the PCS?

I'm not sure I fully understand the PCS. I played with some random hacks
to test_kprobes.c (see below) and the address passed for a big struct
didn't look like the bottom of the stack.

diff --git a/kernel/test_kprobes.c b/kernel/test_kprobes.c
index 0dbab6d1acb4..6ed7be02a560 100644
--- a/kernel/test_kprobes.c
+++ b/kernel/test_kprobes.c
@@ -22,14 +22,18 @@
 
 #define div_factor 3
 
+struct dummy {
+	char dummy_array[MAX_STACK_SIZE * 2];
+};
+
 static u32 rand1, preh_val, posth_val, jph_val;
 static int errors, handler_errors, num_tests;
-static u32 (*target)(u32 value);
+static u32 (*target)(u32 value, struct dummy d);
 static u32 (*target2)(u32 value);
 
-static noinline u32 kprobe_target(u32 value)
+static noinline u32 kprobe_target(u32 value, struct dummy d)
 {
-	return (value / div_factor);
+	return (value / div_factor - d.dummy_array[0] + d.dummy_array[1]);
 }
 
 static int kp_pre_handler(struct kprobe *p, struct pt_regs *regs)
@@ -54,9 +58,11 @@ static struct kprobe kp = {
 	.post_handler = kp_post_handler
 };
 
-static int test_kprobe(void)
+static int noinline test_kprobe(void)
 {
 	int ret;
+	static struct dummy dummy;
+	memset(&dummy, 10, sizeof(dummy));
 
 	ret = register_kprobe(&kp);
 	if (ret < 0) {
@@ -64,7 +70,8 @@ static int test_kprobe(void)
 		return ret;
 	}
 
-	ret = target(rand1);
+	ret = target(rand1, dummy);
+	memset(&dummy, 10, sizeof(dummy));
 	unregister_kprobe(&kp);
 
 	if (preh_val == 0) {
@@ -111,6 +118,8 @@ static int test_kprobes(void)
 {
 	int ret;
 	struct kprobe *kps[2] = {&kp, &kp2};
+	struct dummy dummy;
+	memset(&dummy, 10, sizeof(dummy));
 
 	/* addr and flags should be cleard for reusing kprobe. */
 	kp.addr = NULL;
@@ -123,7 +132,7 @@ static int test_kprobes(void)
 
 	preh_val = 0;
 	posth_val = 0;
-	ret = target(rand1);
+	ret = target(rand1, dummy);
 
 	if (preh_val == 0) {
 		pr_err("kprobe pre_handler not called\n");
@@ -154,7 +163,7 @@ static int test_kprobes(void)
 
 }
 
-static u32 j_kprobe_target(u32 value)
+static u32 j_kprobe_target(u32 value, struct dummy d)
 {
 	if (value != rand1) {
 		handler_errors++;
@@ -174,6 +183,8 @@ static struct jprobe jp = {
 static int test_jprobe(void)
 {
 	int ret;
+	struct dummy dummy;
+	memset(&dummy, 10, sizeof(dummy));
 
 	ret = register_jprobe(&jp);
 	if (ret < 0) {
@@ -181,7 +192,7 @@ static int test_jprobe(void)
 		return ret;
 	}
 
-	ret = target(rand1);
+	ret = target(rand1, dummy);
 	unregister_jprobe(&jp);
 	if (jph_val == 0) {
 		pr_err("jprobe handler not called\n");
@@ -200,6 +211,8 @@ static int test_jprobes(void)
 {
 	int ret;
 	struct jprobe *jps[2] = {&jp, &jp2};
+	struct dummy dummy;
+	memset(&dummy, 10, sizeof(dummy));
 
 	/* addr and flags should be cleard for reusing kprobe. */
 	jp.kp.addr = NULL;
@@ -211,7 +224,7 @@ static int test_jprobes(void)
 	}
 
 	jph_val = 0;
-	ret = target(rand1);
+	ret = target(rand1, dummy);
 	if (jph_val == 0) {
 		pr_err("jprobe handler not called\n");
 		handler_errors++;
@@ -262,6 +275,8 @@ static struct kretprobe rp = {
 static int test_kretprobe(void)
 {
 	int ret;
+	struct dummy dummy;
+	memset(&dummy, 10, sizeof(dummy));
 
 	ret = register_kretprobe(&rp);
 	if (ret < 0) {
@@ -269,7 +284,7 @@ static int test_kretprobe(void)
 		return ret;
 	}
 
-	ret = target(rand1);
+	ret = target(rand1, dummy);
 	unregister_kretprobe(&rp);
 	if (krph_val != rand1) {
 		pr_err("kretprobe handler not called\n");
@@ -306,6 +321,8 @@ static int test_kretprobes(void)
 {
 	int ret;
 	struct kretprobe *rps[2] = {&rp, &rp2};
+	struct dummy dummy;
+	memset(&dummy, 10, sizeof(dummy));
 
 	/* addr and flags should be cleard for reusing kprobe. */
 	rp.kp.addr = NULL;
@@ -317,7 +334,7 @@ static int test_kretprobes(void)
 	}
 
 	krph_val = 0;
-	ret = target(rand1);
+	ret = target(rand1, dummy);
 	if (krph_val != rand1) {
 		pr_err("kretprobe handler not called\n");
 		handler_errors++;

-- 
Catalin

  reply	other threads:[~2016-07-26 16:55 UTC|newest]

Thread overview: 147+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-08 16:35 [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support David Long
2016-07-08 16:35 ` David Long
2016-07-08 16:35 ` [PATCH v15 01/10] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature David Long
2016-07-08 16:35   ` David Long
2016-07-15 10:57   ` Catalin Marinas
2016-07-15 10:57     ` Catalin Marinas
2016-07-15 14:51     ` David Long
2016-07-15 14:51       ` David Long
2016-07-15 15:13       ` Catalin Marinas
2016-07-15 15:13         ` Catalin Marinas
2016-07-15 17:51         ` David Long
2016-07-15 17:51           ` David Long
2016-07-19 14:17           ` Catalin Marinas
2016-07-19 14:17             ` Catalin Marinas
2016-07-08 16:35 ` [PATCH v15 02/10] arm64: Add more test functions to insn.c David Long
2016-07-08 16:35   ` David Long
2016-07-08 16:35 ` [PATCH v15 03/10] arm64: add conditional instruction simulation support David Long
2016-07-08 16:35   ` David Long
2016-07-08 16:35 ` [PATCH v15 04/10] arm64: Kprobes with single stepping support David Long
2016-07-08 16:35   ` David Long
2016-07-20  9:36   ` Marc Zyngier
2016-07-20  9:36     ` Marc Zyngier
2016-07-20 11:16     ` Catalin Marinas
2016-07-20 11:16       ` Catalin Marinas
2016-07-20 19:08     ` David Long
2016-07-20 19:08       ` David Long
2016-07-21  8:44       ` Marc Zyngier
2016-07-21  8:44         ` Marc Zyngier
2016-07-20 15:49   ` Catalin Marinas
2016-07-20 15:49     ` Catalin Marinas
2016-07-21 14:50     ` David Long
2016-07-21 14:50       ` David Long
2016-07-20 16:09   ` Marc Zyngier
2016-07-20 16:09     ` Marc Zyngier
2016-07-20 16:28     ` Catalin Marinas
2016-07-20 16:28       ` Catalin Marinas
2016-07-20 16:31       ` Marc Zyngier
2016-07-20 16:31         ` Marc Zyngier
2016-07-20 16:46       ` Marc Zyngier
2016-07-20 16:46         ` Marc Zyngier
2016-07-20 17:04         ` Catalin Marinas
2016-07-20 17:04           ` Catalin Marinas
2016-07-21 16:33     ` David Long
2016-07-21 16:33       ` David Long
2016-07-21 17:16       ` Catalin Marinas
2016-07-21 17:16         ` Catalin Marinas
2016-07-21 17:23       ` Marc Zyngier
2016-07-21 17:23         ` Marc Zyngier
2016-07-21 18:33         ` David Long
2016-07-21 18:33           ` David Long
2016-07-22 10:16           ` Catalin Marinas
2016-07-22 10:16             ` Catalin Marinas
2016-07-22 15:51             ` David Long
2016-07-22 15:51               ` David Long
2016-07-25 17:13               ` Catalin Marinas
2016-07-25 17:13                 ` Catalin Marinas
2016-07-25 22:27                 ` David Long
2016-07-25 22:27                   ` David Long
2016-07-27 11:50                   ` Daniel Thompson
2016-07-27 11:50                     ` Daniel Thompson
2016-07-27 22:13                     ` David Long
2016-07-27 22:13                       ` David Long
2016-07-28 14:40                       ` Catalin Marinas
2016-07-28 14:40                         ` Catalin Marinas
2016-07-29  9:01                         ` Daniel Thompson
2016-07-29  9:01                           ` Daniel Thompson
2016-08-04  4:47                           ` David Long
2016-08-04  4:47                             ` David Long
2016-08-08 11:13                             ` Daniel Thompson
2016-08-08 11:13                               ` Daniel Thompson
2016-08-08 11:13                               ` Daniel Thompson
2016-08-08 14:29                               ` David Long
2016-08-08 14:29                                 ` David Long
2016-08-08 14:29                                 ` David Long
2016-08-08 22:49                                 ` Masami Hiramatsu
2016-08-08 22:49                                   ` Masami Hiramatsu
2016-08-08 22:49                                   ` Masami Hiramatsu
2016-08-09 17:23                                 ` Catalin Marinas
2016-08-09 17:23                                   ` Catalin Marinas
2016-08-09 17:23                                   ` Catalin Marinas
2016-08-10 20:41                                   ` David Long
2016-08-10 20:41                                     ` David Long
2016-08-10 20:41                                     ` David Long
2016-08-08 22:19                             ` Masami Hiramatsu
2016-08-08 22:19                               ` Masami Hiramatsu
2016-07-26  9:50                 ` Daniel Thompson
2016-07-26  9:50                   ` Daniel Thompson
2016-07-26 16:55                   ` Catalin Marinas [this message]
2016-07-26 16:55                     ` Catalin Marinas
2016-07-27 10:01                     ` Dave Martin
2016-07-27 10:01                       ` Dave Martin
2016-07-26 17:54                   ` Mark Rutland
2016-07-26 17:54                     ` Mark Rutland
2016-07-27 11:19                     ` Daniel Thompson
2016-07-27 11:19                       ` Daniel Thompson
2016-07-27 11:38                       ` Dave Martin
2016-07-27 11:38                         ` Dave Martin
2016-07-27 11:42                         ` Daniel Thompson
2016-07-27 11:42                           ` Daniel Thompson
2016-07-27 13:38                       ` Mark Rutland
2016-07-27 13:38                         ` Mark Rutland
2016-07-08 16:35 ` [PATCH v15 05/10] arm64: Blacklist non-kprobe-able symbol David Long
2016-07-08 16:35   ` David Long
2016-07-08 16:35 ` [PATCH v15 06/10] arm64: Treat all entry code as non-kprobe-able David Long
2016-07-08 16:35   ` David Long
2016-07-15 16:47   ` Catalin Marinas
2016-07-15 16:47     ` Catalin Marinas
2016-07-19  0:53     ` David Long
2016-07-19  0:53       ` David Long
2016-07-08 16:35 ` [PATCH v15 07/10] arm64: kprobes instruction simulation support David Long
2016-07-08 16:35   ` David Long
2016-07-10 22:51   ` Paul Gortmaker
2016-07-10 22:51     ` Paul Gortmaker
2016-07-08 16:35 ` [PATCH v15 08/10] arm64: Add trampoline code for kretprobes David Long
2016-07-08 16:35   ` David Long
2016-07-19 13:46   ` Catalin Marinas
2016-07-19 13:46     ` Catalin Marinas
2016-07-20 18:28     ` David Long
2016-07-20 18:28       ` David Long
2016-07-08 16:35 ` [PATCH v15 09/10] arm64: Add kernel return probes support (kretprobes) David Long
2016-07-08 16:35   ` David Long
2016-07-08 16:35 ` [PATCH v15 10/10] kprobes: Add arm64 case in kprobe example module David Long
2016-07-08 16:35   ` David Long
2016-07-14 16:22 ` [PATCH v15 00/10] arm64: Add kernel probes (kprobes) support Catalin Marinas
2016-07-14 16:22   ` Catalin Marinas
2016-07-14 17:09   ` William Cohen
2016-07-14 17:09     ` William Cohen
2016-07-15  7:50     ` Catalin Marinas
2016-07-15  7:50       ` Catalin Marinas
2016-07-15  8:01       ` Marc Zyngier
2016-07-15  8:01         ` Marc Zyngier
2016-07-15  8:59         ` Alex Bennée
2016-07-15  8:59           ` Alex Bennée
2016-07-15  9:04           ` Marc Zyngier
2016-07-15  9:04             ` Marc Zyngier
2016-07-15  9:53           ` Marc Zyngier
2016-07-15  9:53             ` Marc Zyngier
2016-07-14 17:56   ` David Long
2016-07-14 17:56     ` David Long
2016-07-19 13:57   ` Catalin Marinas
2016-07-19 13:57     ` Catalin Marinas
2016-07-19 14:01     ` David Long
2016-07-19 14:01       ` David Long
2016-07-19 18:27 ` Catalin Marinas
2016-07-19 18:27   ` Catalin Marinas
2016-07-19 19:38   ` David Long
2016-07-19 19:38     ` David Long

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=20160726165543.GG2423@e104818-lin.cambridge.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=Vladimir.Murzin@arm.com \
    --cc=adam.buchbinder@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.bennee@linaro.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=broonie@kernel.org \
    --cc=christoffer.dall@linaro.org \
    --cc=daniel.thompson@linaro.org \
    --cc=dave.long@linaro.org \
    --cc=huawei.libin@huawei.com \
    --cc=james.morse@arm.com \
    --cc=jens.wiklander@linaro.org \
    --cc=john.blackwood@ccur.com \
    --cc=jszhang@marvell.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=mhiramat@kernel.org \
    --cc=panand@redhat.com \
    --cc=pmladek@suse.com \
    --cc=robin.murphy@arm.com \
    --cc=ryabinin.a.a@gmail.com \
    --cc=sandeepa.s.prabhu@gmail.com \
    --cc=shijie.huang@arm.com \
    --cc=steve.capper@linaro.org \
    --cc=suzuki.poulose@arm.com \
    --cc=wcohen@redhat.com \
    --cc=will.deacon@arm.com \
    --cc=yalin.wang2010@gmail.com \
    --cc=yang.shi@linaro.org \
    --cc=zlim.lnx@gmail.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.