On Thu, 1 May 2014, Josh Poimboeuf wrote: > Since Jiri posted the kGraft patches [1], I wanted to share an > alternative live patching solution called kpatch, which is something > we've been working on at Red Hat for quite a while.
Hi Josh, Seth, thanks a lot for following up to our RFC with your submission, I am pretty sure this will help to energize the discussion and will provoke ideas for further improvements. [ ... snip ... ] > 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). Completely agreed with your comparative analysis, thanks for a nice summary. Additional thing that I believe is important to add here: with the "stop-machine / check all tasks" aproach, there might be situations where you'll always fail to patch the system; if there is a long-time sleeper in the patched callchain, such a single sleeper is enough to make the patching of the whole system impossible. With the lazy/gradual aproach implemented in kGraft, the whole system is gradually moving towards "fully patched" state and once all the sleepers blocking the process wake up, it ultimately converges to the fully patched state. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
