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

Takashi Ikebe ikebe.takashi at lab.ntt.co.jp
Mon May 9 18:19:55 PDT 2005


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...).
And there is no open-sourced implementation yet.
I think only the way to realize user space implementation without zero =

modification on legacy application is using ptrace function.

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 <ikebe.takashi at lab.ntt.co.jp> 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
>> cgl_discussion at lists.osdl.org
>> http://lists.osdl.org/mailman/listinfo/cgl_discussion
>>  =

>>
> =


-------------- next part --------------
A non-text attachment was scrubbed...
Name: peekdata.GIF
Type: image/gif
Size: 6636 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/cgl_discussion/attachment=
s/20050510/09fc5b44/peekdata-0001.gif


More information about the cgl_discussion mailing list