All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Seth Jennings <sjenning@redhat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@redhat.com>, Jiri Slaby <jslaby@suse.cz>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching
Date: Fri, 2 May 2014 08:37:51 -0500	[thread overview]
Message-ID: <20140502133751.GB4556@treble.redhat.com> (raw)
In-Reply-To: <alpine.LRH.2.00.1405021504320.22053@twin.jikos.cz>

On Fri, May 02, 2014 at 03:10:58PM +0200, Jiri Kosina wrote:
> On Thu, 1 May 2014, Josh Poimboeuf wrote:
> 
> > kpatch vs kGraft
> > ----------------
> > 
> > I think the biggest difference between kpatch and kGraft is how they
> > ensure that the patch is applied atomically and safely.
> > 
> > kpatch checks the backtraces of all tasks in stop_machine() to ensure
> > that no instances of the old function are running when the new function
> > is applied.  I think the biggest downside of this approach is that
> > stop_machine() has to idle all other CPUs during the patching process,
> > so it inserts a small amount of latency (a few ms on an idle system).
> > 
> > Instead, kGraft uses per-task consistency: each task either sees the old
> > version or the new version of the function.  This gives a consistent
> > view with respect to functions, but _not_ data, because the old and new
> > functions are allowed to run simultaneously and share data.  This could
> > be dangerous if a patch changes how a function uses a data structure.
> > The new function could make a data change that the old function wasn't
> > expecting.
> 
> Please correct me if I am wrong, but with kPatch, you are also unable to 
> do a "flip and forget" switch between functions that expect different 
> format of in-memory data without performing a non-trivial all-memory 
> lookup to find structures in question and perfoming corresponding 
> transformations.
> 
> What we can do with kGraft si to perform the patching in two steps
> 
> (1) redirect to a temporary band-aid function that can handle both 
>     semantics of the data (persumably in highly sub-optimal way)
> (2) patching in (1) succeeds completely (kGraft claims victory), start a 
>     new round of patching with redirect to the final function which 
>     expects only the new semantics
> 
> This basically implies that both aproaches need "human inspection" in this 
> respect anyway.

Ah, interesting.  The intermediate function which knows how to handle
both versions of the data could get pretty tricky though.

With kpatch we'd just need to allow the user to install a callback
function which runs in stop_machine() and manually updates all the data
structures.  I think we'll be implementing something like this soon.

-- 
Josh

  reply	other threads:[~2014-05-02 13:38 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-01 15:52 [RFC PATCH 0/2] kpatch: dynamic kernel patching Josh Poimboeuf
2014-05-01 15:52 ` [RFC PATCH 1/2] kpatch: add TAINT_KPATCH flag Josh Poimboeuf
2014-05-01 15:52 ` [RFC PATCH 2/2] kpatch: add kpatch core module Josh Poimboeuf
2014-05-01 20:45 ` [RFC PATCH 0/2] kpatch: dynamic kernel patching Andi Kleen
2014-05-01 21:01   ` Josh Poimboeuf
2014-05-01 21:06     ` Andi Kleen
2014-05-01 21:27       ` Josh Poimboeuf
2014-05-01 21:39         ` Josh Poimboeuf
2014-05-02  1:30       ` Masami Hiramatsu
2014-05-02  8:37 ` Jiri Kosina
2014-05-02 13:29   ` Josh Poimboeuf
2014-05-02 13:10 ` Jiri Kosina
2014-05-02 13:37   ` Josh Poimboeuf [this message]
2014-05-05 23:34   ` David Lang
2014-05-05 23:52     ` Jiri Kosina
2014-05-06  1:59       ` David Lang
2014-05-06 12:17         ` Josh Poimboeuf
2014-05-06  7:32       ` Ingo Molnar
2014-05-06  8:03         ` Jiri Kosina
2014-05-06 12:23         ` Josh Poimboeuf
2014-05-07 12:19           ` Ingo Molnar
2014-05-09  1:46             ` David Lang
2014-05-09  2:45               ` Steven Rostedt
2014-05-09  4:07               ` Masami Hiramatsu
2014-05-05  8:55 ` Ingo Molnar
2014-05-05 13:26   ` Josh Poimboeuf
2014-05-05 14:10     ` Frederic Weisbecker
2014-05-05 18:43       ` Ingo Molnar
2014-05-05 21:49         ` Frederic Weisbecker
2014-05-06 12:12           ` Josh Poimboeuf
2014-05-06 12:33             ` Steven Rostedt
2014-05-06 22:49               ` Masami Hiramatsu
2014-05-06 14:05             ` Frederic Weisbecker
2014-05-06 14:50               ` Josh Poimboeuf
2014-05-07 12:24                 ` Ingo Molnar
2014-05-07 15:41                   ` Josh Poimboeuf
2014-05-07 15:57                     ` Ingo Molnar
2014-05-07 16:43                       ` Josh Poimboeuf
2014-05-07 22:56                       ` David Lang
2014-05-08  6:12                         ` Ingo Molnar
2014-05-08  6:50                           ` David Lang
2014-05-08  7:08                             ` Ingo Molnar
2014-05-08  7:29                               ` Masami Hiramatsu
2014-05-08 12:48                               ` Josh Poimboeuf
2014-05-09  6:21                                 ` Masami Hiramatsu
2014-06-14 20:31                               ` Pavel Machek
2014-06-15  6:57                                 ` Ingo Molnar
2014-05-06 11:45         ` Masami Hiramatsu
2014-05-06 12:26           ` Steven Rostedt
2014-05-06 22:33             ` Masami Hiramatsu
2014-05-16 16:27             ` Jiri Kosina
2014-05-16 17:14               ` Josh Poimboeuf
2014-05-20  9:37                 ` Jiri Kosina
2014-05-20 12:59                   ` Josh Poimboeuf
2014-05-16 18:09               ` Masami Hiramatsu
2014-05-17 22:46                 ` Vojtech Pavlik
2014-05-16 18:55               ` Steven Rostedt
2014-05-16 22:32                 ` Jiri Kosina
2014-05-17  0:27                   ` Steven Rostedt
2014-05-17  7:10                     ` Jiri Kosina

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=20140502133751.GB4556@treble.redhat.com \
    --to=jpoimboe@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=sjenning@redhat.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.