|From:||Jiri Kosina <jkosina-AT-suse.cz>|
|To:||Josh Poimboeuf <jpoimboe-AT-redhat.com>|
|Subject:||Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching|
|Date:||Fri, 2 May 2014 15:10:58 +0200 (CEST)|
|Cc:||Seth Jennings <sjenning-AT-redhat.com>, Masami Hiramatsu <masami.hiramatsu.pt-AT-hitachi.com>, Steven Rostedt <rostedt-AT-goodmis.org>, Frederic Weisbecker <fweisbec-AT-gmail.com>, Ingo Molnar <mingo-AT-redhat.com>, Jiri Slaby <jslaby-AT-suse.cz>, linux-kernel-AT-vger.kernel.org|
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. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds