[cgl_discussion] Re: [PATCH i386] Live Patching Function on
cminyard at mvista.com
Fri Apr 29 15:33:20 PDT 2005
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.
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 126.96.36.199 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
>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
>cgl_discussion mailing list
>cgl_discussion at lists.osdl.org
More information about the cgl_discussion