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

Takashi Ikebe wrote:

> Hello, Andrew
> Sorry for late reply.
> I don't know montavista's implementation, but it seems some 
> modifications to legacy application are needed(as long as it is 
> implemented as library...).

No modifications are needed.  You can pre-load a shared library to do this.

> And there is no open-sourced implementation yet.

That is true.

> I think only the way to realize user space implementation without zero 
> modification on legacy application is using ptrace function.

You are wrong.  I have implemented this.  Two times, in fact.  Look at 
LD_PRELOAD in the ld.so man page.

I guess if the application was statically linked you couldn't do this 
without linking it in (no modifications to the application would be 
required, just a new library on the link step), but that seems unlikely.

-Corey

>
> We tested ptrace PEEKDATA performance.
> The tested environment is workstation like below.
> CPU Xeon 2.8GHz x2,
> Memory 1GB,
> Kernel 2.6.9
>
> The results are below;
> -------------------------------------------------------------------------------- 
>
> memory-size(byte)    Time-to-write(micro-seconds)
> 1    9
> 10    23
> 50    83
> 100    167
> 500    754
> 1000    1475
> 5000    7259
> 10000    14592
> 50000    73070
> 100000    146037
> 500000    727189
> 1000000    1452708
>
> You can also see liner scaling graph.
> If the patch module is almost 1MB, then it takes almost 1.5second...
> High-throughput ptrace PEEKDATA seems very reasonable(at least for us).
>
>
> Corey Minyard wrote:
>
>> 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
>>>  
>>>
>>
>
>
> ------------------------------------------------------------------------
>