lkml.org 
[lkml]   [2014]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 0/2] kpatch: dynamic kernel patching

* Pavel Machek <pavel@ucw.cz> wrote:

> Hi!
>
> > > in terms of hit-patching kernels you are correct.
> > >
> > > but that's a far cry from what it sounded like you were demanding
> > > (that it must handle any kernel patch)
> >
> > No, I was not demanding that at all, my suggestion was:
> >
> > > My claim is that if a patch is correct/safe in the old fashioned
> > > way, then a fundamental principle is that a live patching
> > > subsystem must either safely apply, or safely reject the live
> > > patching attempt, independently from any user input.
> >
> > Note the 'if'. It could start simple and stupid, and only allow
> > cases where we know the patch must be trivially safe (because it
> > does not do much in terms of disturbing globally visible state).
> > That needs some tooling help, but apparently tooling help is in
> > place already.
>
> Actually, even if patch is very trivial, it will be difficult to
> determine if it is safe. Consider adding error check:
>
> int
> do_something(void)
> {
> #if 0
> if (1)
> return -1;
> #endif
> return 0;
> }
>
> void
> main(void)
> {
> if (do_something())
> printf("error happened\n");
> }
>
> Imagine changing that #if 0 to #if 1. But gcc at -O3 already
> optimized out the error message. So... do we compile whole second
> kernel and compare the binaries? I think I seen remark "don't try to
> do binary compares" somewhere...

Fair enough.

Thanks,

Ingo


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