mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Ingo Molnar <mingo@kernel.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Seth Jennings <sjenning@redhat.com>,
	Ingo Molnar <mingo@redhat.com>, Jiri Slaby <jslaby@suse.cz>,
	linux-kernel@vger.kernel.org,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching
Date: Fri, 16 May 2014 12:14:30 -0500	[thread overview]
Message-ID: <20140516171430.GA15775@treble.redhat.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1405161822050.16459@pobox.suse.cz>

On Fri, May 16, 2014 at 06:27:27PM +0200, Jiri Kosina wrote:
> On Tue, 6 May 2014, Steven Rostedt wrote:
> 
> > > However, I also think if users can accept such freezing wait-time,
> > > it means they can also accept kexec based "checkpoint-restart" patching.
> > > So, I think the final goal of the kpatch will be live patching without
> > > stopping the machine. I'm discussing the issue on github #138, but that is
> > > off-topic. :)
> > 
> > I agree with Ingo too. Being conservative at first is the right
> > approach here. We should start out with a stop_machine making sure that
> > everything is sane before we continue. Sure, that's not much different
> > than a kexec, but lets take things one step at a time.
> > 
> > ftrace did the stop_machine (and still does for some archs), and slowly
> > moved to a more efficient method. kpatch/kgraft should follow suit.
> 
> I don't really agree here.
> 
> I actually believe that "lazy" switching kgraft is doing provides a little 
> bit more in the sense of consistency than stop_machine()-based aproach.
> 
> Consider this scenario:
> 
> 	void foo()
> 	{
> 		for (i=0; i<10000; i++) {
> 			bar(i);
> 			something_else(i);
> 		}
> 	}
> 
> Let's say you want to live-patch bar(). With stop_machine()-based aproach, 
> you can easily end-up with old bar() and new bar() being called in two 
> consecutive iterations before the loop is even exited, right? (especially 
> on preemptible kernel, or if something_else() goes to sleep).

Can you clarify why this would be a problem?  Is it because the new
bar() changed some data semantics which confused foo() or
something_else()?

> 
> With lazy-switching implemented in kgraft, this can never happen.
> 
> So I'd like to ask for a little bit more explanation why you think the 
> stop_machine()-based patching provides more sanity/consistency assurance 
> than the lazy switching we're doing.
> 
> Thanks a lot,
> 
> -- 
> Jiri Kosina
> SUSE Labs

-- 
Josh

  reply	other threads:[~2014-05-16 17:14 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-01 15:52 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
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 [this message]
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=20140516171430.GA15775@treble.redhat.com \
    --to=jpoimboe@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --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@kernel.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=sjenning@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome