Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1321509 > unrolled thread

[PATCH 2/2] ftrace: Adjust priority of ftrace module notifier

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 2/2] ftrace: Adjust priority of ftrace module notifier Jessica Yu <jeyu@redhat.com> - 2016-01-29 07:50 +0100
    Re: [PATCH 2/2] ftrace: Adjust priority of ftrace module notifier Steven Rostedt <rostedt@goodmis.org> - 2016-01-29 15:40 +0100
      Re: [PATCH 2/2] ftrace: Adjust priority of ftrace module notifier Josh Poimboeuf <jpoimboe@redhat.com> - 2016-01-29 16:50 +0100
        Re: [PATCH 2/2] ftrace: Adjust priority of ftrace module notifier Josh Poimboeuf <jpoimboe@redhat.com> - 2016-01-29 17:00 +0100
        Re: [PATCH 2/2] ftrace: Adjust priority of ftrace module notifier Steven Rostedt <rostedt@goodmis.org> - 2016-01-29 17:00 +0100

#1321509 — [PATCH 2/2] ftrace: Adjust priority of ftrace module notifier

Adjust the priority of the ftrace module notifier such that it will run
before the livepatch coming module notifier but after the livepatch going
module modifier.

This fixes a notifier ordering issue in which the ftrace module notifier
(and hence ftrace_module_enable()) for COMING modules was being called
after klp_module_notify(), which caused livepatch modules to initialize
incorrectly.

Signed-off-by: Jessica Yu <jeyu@redhat.com>
---
 kernel/trace/ftrace.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index eca592f..bdd7bfc 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -5067,7 +5067,12 @@ static int ftrace_module_notify(struct notifier_block *self,
 
 struct notifier_block ftrace_module_nb = {
 	.notifier_call = ftrace_module_notify,
-	.priority = INT_MIN,	/* Run after anything that can remove kprobes */
+	/*
+	 * Run after anything that can remove kprobes and
+	 * after livepatch's going notifier, but run before
+	 * livepatch's coming notifier.
+	 */
+	.priority = INT_MIN+1,
 };
 
 void __init ftrace_init(void)
-- 
2.4.3

[toc] | [next] | [standalone]

#1321798

On Fri, 29 Jan 2016 01:43:47 -0500
Jessica Yu <jeyu@redhat.com> wrote:


> ---
>  kernel/trace/ftrace.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index eca592f..bdd7bfc 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -5067,7 +5067,12 @@ static int ftrace_module_notify(struct notifier_block *self,
>  
>  struct notifier_block ftrace_module_nb = {
>  	.notifier_call = ftrace_module_notify,
> -	.priority = INT_MIN,	/* Run after anything that can remove kprobes */
> +	/*
> +	 * Run after anything that can remove kprobes and
> +	 * after livepatch's going notifier, but run before
> +	 * livepatch's coming notifier.
> +	 */
> +	.priority = INT_MIN+1,
>  };
>  
>  void __init ftrace_init(void)

Actually, I rather break up the ftrace notifiers into two different
notifiers. One for coming and one for going (I use to have that before
hard coding the module updates in the module code).

Have the coming notifier be INT_MAX, where it runs before everything
else (which it should, as tracing should be enabled then). And have the
module going to stay INT_MIN to run after everything.

-- Steve

[toc] | [prev] | [next] | [standalone]

#1321841

On Fri, Jan 29, 2016 at 09:38:00AM -0500, Steven Rostedt wrote:
> On Fri, 29 Jan 2016 01:43:47 -0500
> Jessica Yu <jeyu@redhat.com> wrote:
> 
> 
> > ---
> >  kernel/trace/ftrace.c | 7 ++++++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > index eca592f..bdd7bfc 100644
> > --- a/kernel/trace/ftrace.c
> > +++ b/kernel/trace/ftrace.c
> > @@ -5067,7 +5067,12 @@ static int ftrace_module_notify(struct notifier_block *self,
> >  
> >  struct notifier_block ftrace_module_nb = {
> >  	.notifier_call = ftrace_module_notify,
> > -	.priority = INT_MIN,	/* Run after anything that can remove kprobes */
> > +	/*
> > +	 * Run after anything that can remove kprobes and
> > +	 * after livepatch's going notifier, but run before
> > +	 * livepatch's coming notifier.
> > +	 */
> > +	.priority = INT_MIN+1,
> >  };
> >  
> >  void __init ftrace_init(void)
> 
> Actually, I rather break up the ftrace notifiers into two different
> notifiers. One for coming and one for going (I use to have that before
> hard coding the module updates in the module code).
> 
> Have the coming notifier be INT_MAX, where it runs before everything
> else (which it should, as tracing should be enabled then). And have the
> module going to stay INT_MIN to run after everything.

That sounds good to me.

If we do that then I still think it would be a good idea to split up the
livepatch notifiers, with:

- INT_MAX-1 for coming so that relocations are all written before any
  other notifiers (besides ftrace) get a chance to run.

- INT_MIN-1 for going.  I don't have a good specific reason, but I think
  the symmetry will create less surprises and possibly fewer bugs if the
  module's patched state as seen by the other notifiers is the same for
  coming and going.

-- 
Josh

[toc] | [prev] | [next] | [standalone]

#1321847

On Fri, Jan 29, 2016 at 10:49:50AM -0500, Steven Rostedt wrote:
> On Fri, 29 Jan 2016 09:45:05 -0600
> Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> 
> 
> > If we do that then I still think it would be a good idea to split up the
> > livepatch notifiers, with:
> > 
> > - INT_MAX-1 for coming so that relocations are all written before any
> >   other notifiers (besides ftrace) get a chance to run.
> > 
> > - INT_MIN-1 for going.  I don't have a good specific reason, but I think
> 
> Do you mean INT_MIN+1 ?

Er, yeah.

> 
> -- Steve
> 
> >   the symmetry will create less surprises and possibly fewer bugs if the
> >   module's patched state as seen by the other notifiers is the same for
> >   coming and going.
> > 
> 

-- 
Josh

[toc] | [prev] | [next] | [standalone]

#1321848

On Fri, 29 Jan 2016 09:45:05 -0600
Josh Poimboeuf <jpoimboe@redhat.com> wrote:


> If we do that then I still think it would be a good idea to split up the
> livepatch notifiers, with:
> 
> - INT_MAX-1 for coming so that relocations are all written before any
>   other notifiers (besides ftrace) get a chance to run.
> 
> - INT_MIN-1 for going.  I don't have a good specific reason, but I think

Do you mean INT_MIN+1 ?

-- Steve

>   the symmetry will create less surprises and possibly fewer bugs if the
>   module's patched state as seen by the other notifiers is the same for
>   coming and going.
> 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web