Re: Re: [PATCH i386] Live Patching Function on 2.6.11.7

Andrew, you are correct.  This can be implemented as a userspace 
library.  It's not easy, but it can be done.

There are a few things that cannot be handled with hostile 
applications.  For instance, if a thread turns off all signals, it 
cannot be stopped and thus cannot be patched.  However, there are 
important operations that need to be done that are extremely hard to do 
in a ptrace environment and are easy with a library.  I doubt the 
current implementation from NTT has these operations, but they are 
important for patching.

I know this because Montavista delivers a product (which I initially 
wrote) that does exactly this.  It is a set of libraries that the user 
can link in or can be preloaded on an existing application.  We have 
many customers using this tool.

I haven't done any tests, but the library should actually be faster than 
the ptrace method because of the reduced mm switching.  I don't know why 
it would be any slower.  Plus, the actual application of the patch is 
the easy part of this operation; it's all the other stuff you have to do 
that makes this so hard.

I'm not sure I agree with the level of hostility this received.  This is 
an important tool for improving reliability.  I try to stay out of frays 
like this, perhaps to a fault.

-Corey

Andrew Morton wrote:

>Takashi Ikebe <[email protected]> wrote:
>  
>
>>This patch add function called "Live patching" which is defined on
>> OSDL's carrier grade linux requiremnt definition to linux 2.6.11.7 kernel.
>>    
>>
>
>I must say that I'd agree with the hostile reception which this work
>received on the linux-kernel list.
>
>It needs to be exhaustively demonstrated that this functionality cannot be
>provided in userspace.  If it can be implemented in userspace then it would
>be via a library and would require basically zero modifications to legacy
>applications.
>
>If PTRACE_PEEKTEXT/POKETEXT ends up being a limiting factor then we would
>certainly support extensions to the ptrace function which enable higher
>throughput - presumably with scatter/gather lists.
>
>To repeat: I think it _can_ be done in userspace - if the implementation is
>sufficiently good then the limiting factor would be memory bandwidth.
>
>We've seen assertions that a userspace approach would be too slow, but to
>get support for a patch like this, quite frankly, we'd need to see the
>too-slow userspace implementation before we'd agree that kernel help is
>needed.
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>cgl_discussion mailing list
>[email protected]
>http://lists.osdl.org/mailman/listinfo/cgl_discussion
>  
>