Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching

[Jiri Kosina]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/