From: Ingo Molnar <mingo@kernel.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Jiri Kosina <jkosina@suse.cz>, David Lang <david@lang.hm>,
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: Wed, 7 May 2014 14:19:25 +0200 [thread overview]
Message-ID: <20140507121924.GA12234@gmail.com> (raw)
In-Reply-To: <20140506122302.GC4125@treble.redhat.com>
* Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> On Tue, May 06, 2014 at 09:32:28AM +0200, Ingo Molnar wrote:
> >
> > * Jiri Kosina <jkosina@suse.cz> wrote:
> >
> > > On Mon, 5 May 2014, David Lang wrote:
> > >
> > > > how would you know that all instances of the datastructure in memory
> > > > have= been touched? just because all tasks have run and are outside the
> > > > function in question doesn't tell you data structures have been
> > > > converted. You have n= o way of knowing when (or if) the next call to
> > > > the modified function will take place on any potential in-memory
> > > > structure.
> > >
> > > The problem you are trying to avoid here is functions expecting to read
> > > "v2" format of the data from memory, while there are still tasks that are
> > > unpredictably writing "v1" format of the data to the memory.
> > >
> > > There are several ways to attack this problem:
> > >
> > > - stop the whole system, convert all the existing data structures to new
> > > format (which might potentially be non-trivial, mostly because you
> > > have to *know* where all the data structures have been allocated), apply
> > > patch, resume operation [ksplice, probably kpatch in future]
> > > - restrict the data format to be backwards compatible [to be done
> > > manually during patch creation, currently what kGraft needs to do in
> > > such case]
> > > - have a proxy code which can read both "v1" and "v2" formats, and writes
> > > back in the same format it has seen the data structure on input
> > > - once all the *code* has been converted, it still has to understand "v1"
> > > and "v2", but it can now start writing out "v2" format only [possible
> > > with kGraft, not implemented in automated fashion]
> > >
> > > Ideas are of course more than welcome.
> >
> > So what I'm curious about, what is the actual 'in the field' distro
> > experience, about the type of live-patches that get pushed with
> > urgency?
> >
> > My guess would be that the overwhelming majority of live-patches don't
> > change data structures - and hence the right initial model would be to
> > ensure (via tooling, and via review) that 'v1' and 'v2' data is
> > exactly the same.
>
> Yes, in general we want to avoid data changes. In practice, we expect
> most patches to be small, localized security fixes, so it shouldn't be
> an issue in most cases.
>
> Currently the kpatch tooling detects any compile-time changes to
> static data and refuses to build the patch module in that case.
>
> But there's no way to programmatically detect changes to dynamic
> data. Which is why the user always has to be very careful when
> selecting a patch.
And since this is about the system kernel it's dead easy to mess up a
new kernel function and make the system unbootable - so it's not like
'be careful' isn't something implied already.
Thanks,
Ingo
next prev parent reply other threads:[~2014-05-07 12:19 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 [this message]
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=20140507121924.GA12234@gmail.com \
--to=mingo@kernel.org \
--cc=david@lang.hm \
--cc=fweisbec@gmail.com \
--cc=jkosina@suse.cz \
--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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).