lkml.org 
[lkml]   [2014]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 0/2] kpatch: dynamic kernel patching
On Fri, 16 May 2014, Steven Rostedt wrote:

> Why I still favor the stop_machine approach, is because the method of
> patching is a bit simpler that way. A "lazy" approach will be more
> complex and more likely to be buggy. The thing I'm arguing here is not
> the end result being a problem, but the implementation of the patching
> itself causing bugs.

Well, what can I say to this.

21 files changed, 594 insertions(+), 10 deletions(-)

that's a complete implementation, including comments and some
documentation.

Yes, it still has TODOs (such as patching modules as they are modprobed,
we're working on multi-arch support, etc), but it's more or less complete
working x86 skeleton.

> I rather have a "lazy" approach,

I'm glad to hear that, thanks :)

> but like ftrace and its breakpoint method, the stop_machine approach is
> the simpler way to make sure the patching works before we try to
> optimize it.

I am still not convinced that it's more complex. It's actually lazy both
in the way it performs patching and in implementation -- we basically set
a flag, flip the switch, and let the universe converge to a new state by
itself.

It's basically hard to argue about level of bugginess when no actual bugs
are being pointed out :) (well, yes, the kthreads stuff needs to be taken
care of, but both kgraft and kpatch have similar issues there).

Thanks,

--
Jiri Kosina
SUSE Labs


\
 
 \ /
  Last update: 2014-05-17 09:21    [W:0.089 / U:0.784 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site