From: Ingo Molnar <mingo@kernel.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: David Lang <david@lang.hm>, Josh Poimboeuf <jpoimboe@redhat.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Seth Jennings <sjenning@redhat.com>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Steven Rostedt <rostedt@goodmis.org>,
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: Sun, 15 Jun 2014 08:57:31 +0200 [thread overview]
Message-ID: <20140615065731.GB20028@gmail.com> (raw)
In-Reply-To: <20140614203138.GA3853@xo-6d-61-c0.localdomain>
* Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> > > in terms of hit-patching kernels you are correct.
> > >
> > > but that's a far cry from what it sounded like you were demanding
> > > (that it must handle any kernel patch)
> >
> > No, I was not demanding that at all, my suggestion was:
> >
> > > My claim is that if a patch is correct/safe in the old fashioned
> > > way, then a fundamental principle is that a live patching
> > > subsystem must either safely apply, or safely reject the live
> > > patching attempt, independently from any user input.
> >
> > Note the 'if'. It could start simple and stupid, and only allow
> > cases where we know the patch must be trivially safe (because it
> > does not do much in terms of disturbing globally visible state).
> > That needs some tooling help, but apparently tooling help is in
> > place already.
>
> Actually, even if patch is very trivial, it will be difficult to
> determine if it is safe. Consider adding error check:
>
> int
> do_something(void)
> {
> #if 0
> if (1)
> return -1;
> #endif
> return 0;
> }
>
> void
> main(void)
> {
> if (do_something())
> printf("error happened\n");
> }
>
> Imagine changing that #if 0 to #if 1. But gcc at -O3 already
> optimized out the error message. So... do we compile whole second
> kernel and compare the binaries? I think I seen remark "don't try to
> do binary compares" somewhere...
Fair enough.
Thanks,
Ingo
next prev parent reply other threads:[~2014-06-15 6:57 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
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 [this message]
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=20140615065731.GB20028@gmail.com \
--to=mingo@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=david@lang.hm \
--cc=fweisbec@gmail.com \
--cc=jpoimboe@redhat.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@redhat.com \
--cc=pavel@ucw.cz \
--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 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.