Messages in this thread | | | Date | Sat, 17 May 2014 09:10:17 +0200 (CEST) | From | Jiri Kosina <> | Subject | Re: [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
| |