All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails
@ 2015-03-20 14:02 Petr Mladek
  2015-03-23  8:54 ` Ingo Molnar
  0 siblings, 1 reply; 16+ messages in thread
From: Petr Mladek @ 2015-03-20 14:02 UTC (permalink / raw)
  To: Masami Hiramatsu, David S. Miller, Anil S Keshavamurthy,
	Ananth NMavinakayanahalli, Frederic Weisbecker, Steven Rostedt
  Cc: Ingo Molnar, Jiri Kosina, linux-kernel, Petr Mladek

arm_kprobe_ftrace() could fail, especially after introducing ftrace IPMODIFY
flag and LifePatching. But this situation is not properly handled.
This patch adds the most important changes.

First, it does not make sense to register "kprobe_ftrace_ops" if the filter was
not set.

Second, we should remove the filter if the registration of "kprobe_ftrace_ops"
fails. The failure might be caused by conflict between the Kprobe and
a life patch via the IPMODIFY flag. If we remove the filter, we will allow
to register "kprobe_ftrace_ops" for another non-conflicting Kprobe later.

Third, we need to make sure that "kprobe_ftrace_enabled" is incremented only
when "kprobe_ftrace_ops" is successfully registered. Otherwise, another
Kprobe will not try to register it again. Note that we could move the
manipulation with this counter because it is accessed only under "kprobe_mutex".

Four, we should mark the probe as disabled if the ftrace stuff is not usable.
It will be the correct status. Also it will prevent the unregistration code
from producing another failure.

It looks more safe to disable the Kprobe directly in "kprobe_ftrace_ops". Note
that we need to disable also all listed Kprobes in case of an aggregated probe.
It would be enough to disable only the new one but we do not know which one it
was. They should be in sync anyway.

Signed-off-by: Petr Mladek <pmladek@suse.cz>
Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
---
Changes in v3:

  + added brackets for complex if-statement (Steven)

Changes in v2:

  + sent the patch separately
  + added Acked-by Masami

 kernel/kprobes.c | 26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index c90e417bb963..94bd06f57538 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -932,15 +932,33 @@ static int prepare_kprobe(struct kprobe *p)
 /* Caller must lock kprobe_mutex */
 static void arm_kprobe_ftrace(struct kprobe *p)
 {
+	struct kprobe *kp;
 	int ret;
 
 	ret = ftrace_set_filter_ip(&kprobe_ftrace_ops,
 				   (unsigned long)p->addr, 0, 0);
-	WARN(ret < 0, "Failed to arm kprobe-ftrace at %p (%d)\n", p->addr, ret);
-	kprobe_ftrace_enabled++;
-	if (kprobe_ftrace_enabled == 1) {
+	if (WARN(ret < 0,
+		 "Failed to arm kprobe-ftrace at %p (%d). The kprobe gets disabled.\n",
+		 p->addr, ret))
+		goto err_filter;
+
+	if (!kprobe_ftrace_enabled) {
 		ret = register_ftrace_function(&kprobe_ftrace_ops);
-		WARN(ret < 0, "Failed to init kprobe-ftrace (%d)\n", ret);
+		if (WARN(ret < 0,
+			 "Failed to init kprobe-ftrace (%d). The probe at %p gets disabled\n",
+			 ret, p->addr))
+			goto err_function;
+	}
+	kprobe_ftrace_enabled++;
+	return;
+
+err_function:
+	ftrace_set_filter_ip(&kprobe_ftrace_ops, (unsigned long)p->addr, 1, 0);
+err_filter:
+	p->flags |= KPROBE_FLAG_DISABLED;
+	if (kprobe_aggrprobe(p)) {
+		list_for_each_entry_rcu(kp, &p->list, list)
+			kp->flags |= KPROBE_FLAG_DISABLED;
 	}
 }
 
-- 
1.8.5.6


^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails
  2015-03-20 14:02 [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails Petr Mladek
@ 2015-03-23  8:54 ` Ingo Molnar
  2015-03-23 10:12   ` Petr Mladek
  0 siblings, 1 reply; 16+ messages in thread
From: Ingo Molnar @ 2015-03-23  8:54 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Masami Hiramatsu, David S. Miller, Anil S Keshavamurthy,
	Ananth NMavinakayanahalli, Frederic Weisbecker, Steven Rostedt,
	Ingo Molnar, Jiri Kosina, linux-kernel


* Petr Mladek <pmladek@suse.cz> wrote:

> arm_kprobe_ftrace() could fail, especially after introducing ftrace 
> IPMODIFY flag and LifePatching. But this situation is not properly 
> handled.

s/LifePatching/LivePatching?

Why not fix live patching to still allow kprobes that worked before?

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails
  2015-03-23  8:54 ` Ingo Molnar
@ 2015-03-23 10:12   ` Petr Mladek
  2015-03-23 10:33     ` Ingo Molnar
  0 siblings, 1 reply; 16+ messages in thread
From: Petr Mladek @ 2015-03-23 10:12 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Masami Hiramatsu, David S. Miller, Anil S Keshavamurthy,
	Ananth NMavinakayanahalli, Frederic Weisbecker, Steven Rostedt,
	Ingo Molnar, Jiri Kosina, linux-kernel

On Mon 2015-03-23 09:54:26, Ingo Molnar wrote:
> 
> * Petr Mladek <pmladek@suse.cz> wrote:
> 
> > arm_kprobe_ftrace() could fail, especially after introducing ftrace 
> > IPMODIFY flag and LifePatching. But this situation is not properly 
> > handled.
> 
> s/LifePatching/LivePatching?

Great catch! This is well hidden typo. Please, find the fixed version
below.


> Why not fix live patching to still allow kprobes that worked before?

Yup, Kretprobes would work out of box. Masami is working on removing
the conflict there.

Jprobes are doable but the solution would be rather complicated.
LivePatching would need to tell Jprobe the right address where to
continue (according to the universe). We currently solve this by
the conflict. I am not sure if a better solution is worth the effort.
IMHO, LivePatch users won't want to have Kprobes on a production
system all the time. They could use Kprobe or attach Jprobe to the
new version of the function when needed.

Kprobes are basically impossible to keep if they are attached inside
the patched function. We would need to disassemble the code and guess
the location. Instead, we are going to print warning when a Kprobe
will get ignored.


Below is the patch with the fixed typo.


>From 1cc3e6f44462bdad651bdd75c87a5c7ed884bec5 Mon Sep 17 00:00:00 2001
From: Petr Mladek <pmladek@suse.cz>
Date: Fri, 6 Feb 2015 17:46:20 +0100
Subject: [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails

arm_kprobe_ftrace() could fail, especially after introducing ftrace IPMODIFY
flag and LivePatching. But this situation is not properly handled.
This patch adds the most important changes.

First, it does not make sense to register "kprobe_ftrace_ops" if the filter was
not set.

Second, we should remove the filter if the registration of "kprobe_ftrace_ops"
fails. The failure might be caused by conflict between the Kprobe and
a life patch via the IPMODIFY flag. If we remove the filter, we will allow
to register "kprobe_ftrace_ops" for another non-conflicting Kprobe later.

Third, we need to make sure that "kprobe_ftrace_enabled" is incremented only
when "kprobe_ftrace_ops" is successfully registered. Otherwise, another
Kprobe will not try to register it again. Note that we could move the
manipulation with this counter because it is accessed only under "kprobe_mutex".

Four, we should mark the probe as disabled if the ftrace stuff is not usable.
It will be the correct status. Also it will prevent the unregistration code
from producing another failure.

It looks more safe to disable the Kprobe directly in "kprobe_ftrace_ops". Note
that we need to disable also all listed Kprobes in case of an aggregated probe.
It would be enough to disable only the new one but we do not know which one it
was. They should be in sync anyway.

Signed-off-by: Petr Mladek <pmladek@suse.cz>
Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
---
Changes in v3:

  + added brackets for complex if-statement (Steven)

Changes in v2:

  + sent the patch separately
  + added Acked-by Masami

 kernel/kprobes.c | 26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index c90e417bb963..94bd06f57538 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -932,15 +932,33 @@ static int prepare_kprobe(struct kprobe *p)
 /* Caller must lock kprobe_mutex */
 static void arm_kprobe_ftrace(struct kprobe *p)
 {
+	struct kprobe *kp;
 	int ret;
 
 	ret = ftrace_set_filter_ip(&kprobe_ftrace_ops,
 				   (unsigned long)p->addr, 0, 0);
-	WARN(ret < 0, "Failed to arm kprobe-ftrace at %p (%d)\n", p->addr, ret);
-	kprobe_ftrace_enabled++;
-	if (kprobe_ftrace_enabled == 1) {
+	if (WARN(ret < 0,
+		 "Failed to arm kprobe-ftrace at %p (%d). The kprobe gets disabled.\n",
+		 p->addr, ret))
+		goto err_filter;
+
+	if (!kprobe_ftrace_enabled) {
 		ret = register_ftrace_function(&kprobe_ftrace_ops);
-		WARN(ret < 0, "Failed to init kprobe-ftrace (%d)\n", ret);
+		if (WARN(ret < 0,
+			 "Failed to init kprobe-ftrace (%d). The probe at %p gets disabled\n",
+			 ret, p->addr))
+			goto err_function;
+	}
+	kprobe_ftrace_enabled++;
+	return;
+
+err_function:
+	ftrace_set_filter_ip(&kprobe_ftrace_ops, (unsigned long)p->addr, 1, 0);
+err_filter:
+	p->flags |= KPROBE_FLAG_DISABLED;
+	if (kprobe_aggrprobe(p)) {
+		list_for_each_entry_rcu(kp, &p->list, list)
+			kp->flags |= KPROBE_FLAG_DISABLED;
 	}
 }
 
-- 
1.8.5.6


^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails
  2015-03-23 10:12   ` Petr Mladek
@ 2015-03-23 10:33     ` Ingo Molnar
  2015-03-23 12:39       ` Petr Mladek
  0 siblings, 1 reply; 16+ messages in thread
From: Ingo Molnar @ 2015-03-23 10:33 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Masami Hiramatsu, David S. Miller, Anil S Keshavamurthy,
	Ananth NMavinakayanahalli, Frederic Weisbecker, Steven Rostedt,
	Ingo Molnar, Jiri Kosina, linux-kernel


* Petr Mladek <pmladek@suse.cz> wrote:

> On Mon 2015-03-23 09:54:26, Ingo Molnar wrote:
> > 
> > * Petr Mladek <pmladek@suse.cz> wrote:
> > 
> > > arm_kprobe_ftrace() could fail, especially after introducing ftrace 
> > > IPMODIFY flag and LifePatching. But this situation is not properly 
> > > handled.
> > 
> > s/LifePatching/LivePatching?
> 
> Great catch! This is well hidden typo. Please, find the fixed version
> below.
> 
> 
> > Why not fix live patching to still allow kprobes that worked before?
> 
> Yup, Kretprobes would work out of box. Masami is working on removing
> the conflict there.
> 
> Jprobes are doable but the solution would be rather complicated. 
> LivePatching would need to tell Jprobe the right address where to 
> continue (according to the universe). We currently solve this by

wth is a 'universe' in this context?

> the conflict. I am not sure if a better solution is worth the effort.
> IMHO, LivePatch users won't want to have Kprobes on a production
> system all the time. They could use Kprobe or attach Jprobe to the
> new version of the function when needed.

So please outline the current usage limitations, why those limitations 
are in place and how you see they should be fixed/addressed.

> Below is the patch with the fixed typo.

So the typo is totally immaterial compared to the above fundamental 
patch-coordination problems between live patching, ftrace and kprobes 
...

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails
  2015-03-23 10:33     ` Ingo Molnar
@ 2015-03-23 12:39       ` Petr Mladek
  2015-03-23 13:30         ` Steven Rostedt
  0 siblings, 1 reply; 16+ messages in thread
From: Petr Mladek @ 2015-03-23 12:39 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Masami Hiramatsu, David S. Miller, Anil S Keshavamurthy,
	Ananth NMavinakayanahalli, Frederic Weisbecker, Steven Rostedt,
	Ingo Molnar, Jiri Kosina, linux-kernel

On Mon 2015-03-23 11:33:27, Ingo Molnar wrote:
> 
> * Petr Mladek <pmladek@suse.cz> wrote:
> 
> > On Mon 2015-03-23 09:54:26, Ingo Molnar wrote:
> > > 
> > > * Petr Mladek <pmladek@suse.cz> wrote:
> > > 
> > > > arm_kprobe_ftrace() could fail, especially after introducing ftrace 
> > > > IPMODIFY flag and LifePatching. But this situation is not properly 
> > > > handled.
> > > 
> > > s/LifePatching/LivePatching?
> > 
> > Great catch! This is well hidden typo. Please, find the fixed version
> > below.
> > 
> > 
> > > Why not fix live patching to still allow kprobes that worked before?
> > 
> > Yup, Kretprobes would work out of box. Masami is working on removing
> > the conflict there.
> > 
> > Jprobes are doable but the solution would be rather complicated. 
> > LivePatching would need to tell Jprobe the right address where to 
> > continue (according to the universe). We currently solve this by
> 
> wth is a 'universe' in this context?

We use the term "universe" to define whether the system or task uses
original or patched functions. It is especially important for patches
that modify semantic of functions. They need more complex consistency
model. It defines when it is safe time for the system or task to start
using the new functions (switch to the new universe).

In theory, different tasks might be in more universes if more patches are
being applied. In practice, we deal with only two universes. The trick is
that we allow to add new patch only when the whole system has switched
to the previous one.

Note that the current implementation does not support changes in
the function semantic. Therefore it is safe to start using the new
function immediately. It does not need any coordination.


> > the conflict. I am not sure if a better solution is worth the effort.
> > IMHO, LivePatch users won't want to have Kprobes on a production
> > system all the time. They could use Kprobe or attach Jprobe to the
> > new version of the function when needed.
> 
> So please outline the current usage limitations, why those limitations 
> are in place and how you see they should be fixed/addressed.

Good point, we should add some info under Documentation/


> > Below is the patch with the fixed typo.
> 
> So the typo is totally immaterial compared to the above fundamental 
> patch-coordination problems between live patching, ftrace and kprobes 
> ...

This patch makes sense even without live patching and IPMODIFY. The
ftrace operation might have failed even before and deserved some
sensible handling.

And yes, the coordination between live patching and kprobes has
to be improved. Masami and me are working on it.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails
  2015-03-23 12:39       ` Petr Mladek
@ 2015-03-23 13:30         ` Steven Rostedt
  2015-03-23 13:34           ` Ingo Molnar
  0 siblings, 1 reply; 16+ messages in thread
From: Steven Rostedt @ 2015-03-23 13:30 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Ingo Molnar, Masami Hiramatsu, David S. Miller,
	Anil S Keshavamurthy, Ananth NMavinakayanahalli,
	Frederic Weisbecker, Ingo Molnar, Jiri Kosina, linux-kernel

On Mon, 23 Mar 2015 13:39:55 +0100
Petr Mladek <pmladek@suse.cz> wrote:


> > wth is a 'universe' in this context?
> 
> We use the term "universe" to define whether the system or task uses
> original or patched functions. It is especially important for patches
> that modify semantic of functions. They need more complex consistency
> model. It defines when it is safe time for the system or task to start
> using the new functions (switch to the new universe).
> 
> In theory, different tasks might be in more universes if more patches are
> being applied. In practice, we deal with only two universes. The trick is
> that we allow to add new patch only when the whole system has switched
> to the previous one.
> 

Is this terminology documented anywhere upstream yet?

-- Steve

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails
  2015-03-23 13:30         ` Steven Rostedt
@ 2015-03-23 13:34           ` Ingo Molnar
  2015-03-23 13:43             ` Steven Rostedt
  2015-03-23 22:36             ` Jiri Kosina
  0 siblings, 2 replies; 16+ messages in thread
From: Ingo Molnar @ 2015-03-23 13:34 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Petr Mladek, Masami Hiramatsu, David S. Miller,
	Anil S Keshavamurthy, Ananth NMavinakayanahalli,
	Frederic Weisbecker, Ingo Molnar, Jiri Kosina, linux-kernel


* Steven Rostedt <rostedt@goodmis.org> wrote:

> On Mon, 23 Mar 2015 13:39:55 +0100
> Petr Mladek <pmladek@suse.cz> wrote:
> 
> 
> > > wth is a 'universe' in this context?
> > 
> > We use the term "universe" to define whether the system or task uses
> > original or patched functions. It is especially important for patches
> > that modify semantic of functions. They need more complex consistency
> > model. It defines when it is safe time for the system or task to start
> > using the new functions (switch to the new universe).
> > 
> > In theory, different tasks might be in more universes if more patches are
> > being applied. In practice, we deal with only two universes. The trick is
> > that we allow to add new patch only when the whole system has switched
> > to the previous one.
> > 
> 
> Is this terminology documented anywhere upstream yet?

Even if it was documented (it isn't), it's pretty weird terminology - 
please use clearer formulations, like 'patched function' or 'unpatched 
function' or 'function with pending patch'. No need to redefine 
existing words in a weird fashion just to create the appearance of 
being special ...

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails
  2015-03-23 13:34           ` Ingo Molnar
@ 2015-03-23 13:43             ` Steven Rostedt
  2015-03-23 13:53               ` Ingo Molnar
  2015-03-23 16:43               ` Paul E. McKenney
  2015-03-23 22:36             ` Jiri Kosina
  1 sibling, 2 replies; 16+ messages in thread
From: Steven Rostedt @ 2015-03-23 13:43 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Petr Mladek, Masami Hiramatsu, David S. Miller,
	Anil S Keshavamurthy, Ananth NMavinakayanahalli,
	Frederic Weisbecker, Ingo Molnar, Jiri Kosina, linux-kernel,
	Paul E. McKenney

On Mon, 23 Mar 2015 14:34:42 +0100
Ingo Molnar <mingo@kernel.org> wrote:
> 
> Even if it was documented (it isn't), it's pretty weird terminology - 
> please use clearer formulations, like 'patched function' or 'unpatched 
> function' or 'function with pending patch'. No need to redefine 
> existing words in a weird fashion just to create the appearance of 
> being special ...
> 

I think it has to do with their RCU like patching functionality, where
some tasks are still executing the old function and others are
executing the new function. In RCU, there's two "universes" too. One
with the old value, and one with the new. After the grace period has
finished, everything is back to a single "universe".

I'm not sure RCU uses the term "universe" though. Paul?

-- Steve

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails
  2015-03-23 13:43             ` Steven Rostedt
@ 2015-03-23 13:53               ` Ingo Molnar
  2015-03-23 13:58                 ` Steven Rostedt
  2015-03-23 16:43               ` Paul E. McKenney
  1 sibling, 1 reply; 16+ messages in thread
From: Ingo Molnar @ 2015-03-23 13:53 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Petr Mladek, Masami Hiramatsu, David S. Miller,
	Anil S Keshavamurthy, Ananth NMavinakayanahalli,
	Frederic Weisbecker, Ingo Molnar, Jiri Kosina, linux-kernel,
	Paul E. McKenney


* Steven Rostedt <rostedt@goodmis.org> wrote:

> On Mon, 23 Mar 2015 14:34:42 +0100
> Ingo Molnar <mingo@kernel.org> wrote:
> > 
> > Even if it was documented (it isn't), it's pretty weird terminology - 
> > please use clearer formulations, like 'patched function' or 'unpatched 
> > function' or 'function with pending patch'. No need to redefine 
> > existing words in a weird fashion just to create the appearance of 
> > being special ...
> > 
> 
> I think it has to do with their RCU like patching functionality, 
> where some tasks are still executing the old function and others are 
> executing the new function. [...]

That would be the 'function with pending patch' state in my 
description above.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails
  2015-03-23 13:53               ` Ingo Molnar
@ 2015-03-23 13:58                 ` Steven Rostedt
  2015-03-23 16:38                   ` Petr Mladek
  0 siblings, 1 reply; 16+ messages in thread
From: Steven Rostedt @ 2015-03-23 13:58 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Petr Mladek, Masami Hiramatsu, David S. Miller,
	Anil S Keshavamurthy, Ananth NMavinakayanahalli,
	Frederic Weisbecker, Ingo Molnar, Jiri Kosina, linux-kernel,
	Paul E. McKenney

On Mon, 23 Mar 2015 14:53:06 +0100
Ingo Molnar <mingo@kernel.org> wrote:


> > I think it has to do with their RCU like patching functionality, 
> > where some tasks are still executing the old function and others are 
> > executing the new function. [...]
> 
> That would be the 'function with pending patch' state in my 
> description above.

That could be considered a bit confusing too, because the patch isn't
pending, it's already applied. But this is getting off topic, as the
code for this isn't even in mainline yet, so I agree that the use of
terminology that has not been upstreamed yet should be avoided.

-- Steve

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails
  2015-03-23 13:58                 ` Steven Rostedt
@ 2015-03-23 16:38                   ` Petr Mladek
  0 siblings, 0 replies; 16+ messages in thread
From: Petr Mladek @ 2015-03-23 16:38 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Ingo Molnar, Masami Hiramatsu, David S. Miller,
	Anil S Keshavamurthy, Ananth NMavinakayanahalli,
	Frederic Weisbecker, Ingo Molnar, Jiri Kosina, linux-kernel,
	Paul E. McKenney

On Mon 2015-03-23 09:58:53, Steven Rostedt wrote:
> On Mon, 23 Mar 2015 14:53:06 +0100
> Ingo Molnar <mingo@kernel.org> wrote:
> 
> 
> > > I think it has to do with their RCU like patching functionality, 
> > > where some tasks are still executing the old function and others are 
> > > executing the new function. [...]
> > 
> > That would be the 'function with pending patch' state in my 
> > description above.
> 
> That could be considered a bit confusing too, because the patch isn't
> pending, it's already applied. But this is getting off topic, as the
> code for this isn't even in mainline yet, so I agree that the use of
> terminology that has not been upstreamed yet should be avoided.

I am sorry for confusion. I will be more careful about the terminology
in my mails.

Anyway, I did not use the word because I wanted to be special. I
joined the team working on kGraft (SUSE live patch implementation)
when the work was already in progress. This term was used there
heavily. You know, I have used it for too long and somehow forgot
that many other people were not familiar with it.

And yes, it is similar to RCU terminology. If we added support
for patches that modify semantic of functions, there would be
three states as well:

  1. no patch

  2. patch is added; ftrace handler is added but it does _not_
     redirect the code; the old function is still used because there has
     not been a safe point for the switch yet

  3. patch is added; ftrace handler is added and it redirects the call
     to the new implementation from the patch


The second state is similar to RCU intermediate state. A list has
been modified but some thread might still see the old state.


Best Regards,
Petr

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails
  2015-03-23 13:43             ` Steven Rostedt
  2015-03-23 13:53               ` Ingo Molnar
@ 2015-03-23 16:43               ` Paul E. McKenney
  2015-03-23 23:32                 ` Jiri Kosina
  1 sibling, 1 reply; 16+ messages in thread
From: Paul E. McKenney @ 2015-03-23 16:43 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Ingo Molnar, Petr Mladek, Masami Hiramatsu, David S. Miller,
	Anil S Keshavamurthy, Ananth NMavinakayanahalli,
	Frederic Weisbecker, Ingo Molnar, Jiri Kosina, linux-kernel

On Mon, Mar 23, 2015 at 09:43:17AM -0400, Steven Rostedt wrote:
> On Mon, 23 Mar 2015 14:34:42 +0100
> Ingo Molnar <mingo@kernel.org> wrote:
> > 
> > Even if it was documented (it isn't), it's pretty weird terminology - 
> > please use clearer formulations, like 'patched function' or 'unpatched 
> > function' or 'function with pending patch'. No need to redefine 
> > existing words in a weird fashion just to create the appearance of 
> > being special ...
> > 
> 
> I think it has to do with their RCU like patching functionality, where
> some tasks are still executing the old function and others are
> executing the new function. In RCU, there's two "universes" too. One
> with the old value, and one with the new. After the grace period has
> finished, everything is back to a single "universe".
> 
> I'm not sure RCU uses the term "universe" though. Paul?

I have used "version" for what you call "universe", but mostly in
"intro to RCU" guest lectures.

							Thanx, Paul


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails
  2015-03-23 13:34           ` Ingo Molnar
  2015-03-23 13:43             ` Steven Rostedt
@ 2015-03-23 22:36             ` Jiri Kosina
  2015-03-24  7:59               ` Petr Mladek
  1 sibling, 1 reply; 16+ messages in thread
From: Jiri Kosina @ 2015-03-23 22:36 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Steven Rostedt, Petr Mladek, Masami Hiramatsu, David S. Miller,
	Anil S Keshavamurthy, Ananth NMavinakayanahalli,
	Frederic Weisbecker, Ingo Molnar, linux-kernel

On Mon, 23 Mar 2015, Ingo Molnar wrote:

> > > > wth is a 'universe' in this context?
> > > 
> > > We use the term "universe" to define whether the system or task uses
> > > original or patched functions. It is especially important for patches
> > > that modify semantic of functions. They need more complex consistency
> > > model. It defines when it is safe time for the system or task to start
> > > using the new functions (switch to the new universe).
> > > 
> > > In theory, different tasks might be in more universes if more patches are
> > > being applied. In practice, we deal with only two universes. The trick is
> > > that we allow to add new patch only when the whole system has switched
> > > to the previous one.
> > > 
> > 
> > Is this terminology documented anywhere upstream yet?
> 
> Even if it was documented (it isn't), 

There is no point in documenting it upstream, as no upstream code is using 
this "universe" notation. It should just be removed from original Petr's 
changelog and that's it.

> it's pretty weird terminology - please use clearer formulations, like 
> 'patched function' or 'unpatched function' or 'function with pending 
> patch'.

All your suggestions above unfortunately don't really reflect what is 
happening when lazy per-thread migration is applied.

> No need to redefine existing words in a weird fashion just to create the 
> appearance of being special ...

So which particular existing word(s) are you talking about here?

Thanks,

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails
  2015-03-23 16:43               ` Paul E. McKenney
@ 2015-03-23 23:32                 ` Jiri Kosina
  0 siblings, 0 replies; 16+ messages in thread
From: Jiri Kosina @ 2015-03-23 23:32 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Steven Rostedt, Ingo Molnar, Petr Mladek, Masami Hiramatsu,
	David S. Miller, Anil S Keshavamurthy, Ananth NMavinakayanahalli,
	Frederic Weisbecker, Ingo Molnar, linux-kernel

On Mon, 23 Mar 2015, Paul E. McKenney wrote:

> > > Even if it was documented (it isn't), it's pretty weird terminology - 
> > > please use clearer formulations, like 'patched function' or 'unpatched 
> > > function' or 'function with pending patch'. No need to redefine 
> > > existing words in a weird fashion just to create the appearance of 
> > > being special ...
> > > 
> > 
> > I think it has to do with their RCU like patching functionality, where
> > some tasks are still executing the old function and others are
> > executing the new function. In RCU, there's two "universes" too. One
> > with the old value, and one with the new. After the grace period has
> > finished, everything is back to a single "universe".
> > 
> > I'm not sure RCU uses the term "universe" though. Paul?
> 
> I have used "version" for what you call "universe", but mostly in
> "intro to RCU" guest lectures.

Yup, exactly. Even kGraft (which is where the 'universe' term referring to 
the function versioning in lazy migration is very likely coming from) 
doesn't really use the term 'universe' itself anywhere in the sources as 
any kind of identifier. It's always used solely as a term that's intended 
to simplify the basic understanding of how the whole process works, and 
that's pretty much it. I don't even think it deserves so lively discussion 
:)

Thanks,

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails
  2015-03-23 22:36             ` Jiri Kosina
@ 2015-03-24  7:59               ` Petr Mladek
  2015-03-24 13:36                 ` Steven Rostedt
  0 siblings, 1 reply; 16+ messages in thread
From: Petr Mladek @ 2015-03-24  7:59 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: Ingo Molnar, Steven Rostedt, Masami Hiramatsu, David S. Miller,
	Anil S Keshavamurthy, Ananth NMavinakayanahalli,
	Frederic Weisbecker, Ingo Molnar, linux-kernel

On Mon 2015-03-23 23:36:00, Jiri Kosina wrote:
> On Mon, 23 Mar 2015, Ingo Molnar wrote:
> 
> > > > > wth is a 'universe' in this context?
> > > > 
> > > > We use the term "universe" to define whether the system or task uses
> > > > original or patched functions. It is especially important for patches
> > > > that modify semantic of functions. They need more complex consistency
> > > > model. It defines when it is safe time for the system or task to start
> > > > using the new functions (switch to the new universe).
> > > > 
> > > > In theory, different tasks might be in more universes if more patches are
> > > > being applied. In practice, we deal with only two universes. The trick is
> > > > that we allow to add new patch only when the whole system has switched
> > > > to the previous one.
> > > > 
> > > 
> > > Is this terminology documented anywhere upstream yet?
> > 
> > Even if it was documented (it isn't), 
> 
> There is no point in documenting it upstream, as no upstream code is using 
> this "universe" notation. It should just be removed from original Petr's 
> changelog and that's it.

Note that the term "universe" is not used in the commit message => no
change is needed.

I used the term to answer the question about interference between
Jprobes, ftrace, and live patches. I am sorry again. I should have
described it in a broader context.


Anyway, please, let me to repeat. This patch makes sense even without
live patching. The ftrace operations were there even before and might
have failed.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails
  2015-03-24  7:59               ` Petr Mladek
@ 2015-03-24 13:36                 ` Steven Rostedt
  0 siblings, 0 replies; 16+ messages in thread
From: Steven Rostedt @ 2015-03-24 13:36 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Jiri Kosina, Ingo Molnar, Masami Hiramatsu, David S. Miller,
	Anil S Keshavamurthy, Ananth NMavinakayanahalli,
	Frederic Weisbecker, Ingo Molnar, linux-kernel

On Tue, 24 Mar 2015 08:59:25 +0100
Petr Mladek <pmladek@suse.cz> wrote:


> I used the term to answer the question about interference between
> Jprobes, ftrace, and live patches. I am sorry again. I should have
> described it in a broader context.

Don't be sorry. It wasn't a big deal ;-)

> 
> 
> Anyway, please, let me to repeat. This patch makes sense even without
> live patching. The ftrace operations were there even before and might
> have failed.

I'll have to take a deeper look at the patch again. I'll give it a
review.

-- Steve


^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2015-03-24 13:36 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-20 14:02 [PATCH v3] kprobes: Disable Kprobe when ftrace arming fails Petr Mladek
2015-03-23  8:54 ` Ingo Molnar
2015-03-23 10:12   ` Petr Mladek
2015-03-23 10:33     ` Ingo Molnar
2015-03-23 12:39       ` Petr Mladek
2015-03-23 13:30         ` Steven Rostedt
2015-03-23 13:34           ` Ingo Molnar
2015-03-23 13:43             ` Steven Rostedt
2015-03-23 13:53               ` Ingo Molnar
2015-03-23 13:58                 ` Steven Rostedt
2015-03-23 16:38                   ` Petr Mladek
2015-03-23 16:43               ` Paul E. McKenney
2015-03-23 23:32                 ` Jiri Kosina
2015-03-23 22:36             ` Jiri Kosina
2015-03-24  7:59               ` Petr Mladek
2015-03-24 13:36                 ` Steven Rostedt

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.