All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Jessica Yu <jeyu@redhat.com>, Seth Jennings <sjenning@redhat.com>,
	Jiri Kosina <jikos@kernel.org>, Vojtech Pavlik <vojtech@suse.com>,
	Miroslav Benes <mbenes@suse.cz>, Ingo Molnar <mingo@redhat.com>,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] ftrace: Adjust priority of ftrace module notifier
Date: Fri, 29 Jan 2016 09:45:05 -0600	[thread overview]
Message-ID: <20160129154505.GF4081@treble.redhat.com> (raw)
In-Reply-To: <20160129093800.6c739e40@gandalf.local.home>

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

  reply	other threads:[~2016-01-29 15:45 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-29  6:43 [PATCH 0/2] Fix ordering of ftrace + livepatch module notifier callbacks Jessica Yu
2016-01-29  6:43 ` [PATCH 1/2] livepatch: Implement separate coming and going module notifiers Jessica Yu
2016-01-29 16:30   ` Miroslav Benes
2016-01-29 17:30     ` Josh Poimboeuf
2016-01-29 17:40       ` Steven Rostedt
2016-01-29 17:58         ` Josh Poimboeuf
2016-01-29 19:25           ` Miroslav Benes
2016-01-29 19:29             ` Steven Rostedt
2016-01-29 19:47               ` Josh Poimboeuf
2016-01-29 20:08                 ` Steven Rostedt
2016-01-29 20:15                   ` Josh Poimboeuf
2016-02-01 12:27                     ` Jiri Kosina
2016-02-01 14:48                       ` Josh Poimboeuf
2016-01-29 19:51               ` Jessica Yu
2016-01-29 19:42             ` [PATCH 1/2] " Josh Poimboeuf
2016-01-29 22:58               ` Jessica Yu
2016-01-30  0:02                 ` Steven Rostedt
2016-02-01 14:37                 ` Josh Poimboeuf
2016-01-29 20:04       ` Jessica Yu
2016-01-29 20:09         ` Steven Rostedt
2016-01-29 20:10           ` Steven Rostedt
2016-01-29 20:20         ` Josh Poimboeuf
2016-01-29  6:43 ` [PATCH 2/2] ftrace: Adjust priority of ftrace module notifier Jessica Yu
2016-01-29 14:38   ` Steven Rostedt
2016-01-29 15:45     ` Josh Poimboeuf [this message]
2016-01-29 15:49       ` Steven Rostedt
2016-01-29 15:50         ` Josh Poimboeuf

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=20160129154505.GF4081@treble.redhat.com \
    --to=jpoimboe@redhat.com \
    --cc=jeyu@redhat.com \
    --cc=jikos@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=sjenning@redhat.com \
    --cc=vojtech@suse.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.