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

[Jiri Kosina]

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
--
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/