All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Miroslav Benes <mbenes@suse.cz>, Jessica Yu <jeyu@redhat.com>,
	Seth Jennings <sjenning@redhat.com>,
	Jiri Kosina <jikos@kernel.org>, Vojtech Pavlik <vojtech@suse.com>,
	Ingo Molnar <mingo@redhat.com>,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
	Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH 1/2] livepatch: Implement separate coming and going module notifiers
Date: Fri, 29 Jan 2016 14:15:34 -0600	[thread overview]
Message-ID: <20160129201534.GE19101@treble.redhat.com> (raw)
In-Reply-To: <20160129150823.14a5d17e@gandalf.local.home>

On Fri, Jan 29, 2016 at 03:08:23PM -0500, Steven Rostedt wrote:
> On Fri, 29 Jan 2016 13:47:15 -0600
> Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> 
> 
> > > Although, I have to admit, if live kernel patching is configured in,
> > > it's not always needed to be called here, does it? With ftrace, the
> > > call has to be done when ftrace is configured in regardless if tracing
> > > is used or not.  
> > 
> > For live patching it actually does need to be called for every module.
> > We need to check if any previously loaded patches have any modifications
> > which affect the module.
> > 
> 
> But only if you are using the live kernel patching facility. My point
> is, if I never use live kernel patching (which 99.9% of Linux users do
> no use), then the call will basically be a nop.
> 
> With ftrace, that's not the story. Even if you don't ever use the
> facility (like 99.8% of Linux users do not use ;-) the function is
> still not a nop. There's three calls needed for each module.
> 
> 1) convert all the calls to mcount/fentry into a nop, and save
> those locations in a table. They are all marked as disabled (not to be
> used)
> 
> 2) After module setup (where the notifiers are called), the locations
> need to be enabled, otherwise ftrace would never work for that module.
> 
> 3) On module exit, the locations must be removed, otherwise ftrace may
> still try to write to non-existing code which could brick specific
> network cards.
> 
> These are done if ftrace is configured regardless if it is every
> actually used by a user.
> 
> Thus, my question is, what does live kernel patching need to do if I
> never add a patch?

Right, as you say it's basically a nop 99.99% of the time.  But we still
need to do the "are any patches loaded" check, so we still need the call
into a livepatch function to do that.

-- 
Josh

  reply	other threads:[~2016-01-29 20:15 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 [this message]
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
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=20160129201534.GE19101@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=rusty@rustcorp.com.au \
    --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.