public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Takashi Ikebe <ikebe.takashi@lab.ntt.co.jp>
To: Daniel Jacobowitz <dan@debian.org>
Cc: "David S. Miller" <davem@davemloft.net>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i386 & x86_64: Live Patching Funcion on 2.6.11.7
Date: Mon, 18 Apr 2005 14:20:42 +0900	[thread overview]
Message-ID: <426343AA.4090602@lab.ntt.co.jp> (raw)
In-Reply-To: <20050418044115.GA15002@nevyn.them.org>

Daniel Jacobowitz wrote:

>On Mon, Apr 18, 2005 at 10:41:23AM +0900, Takashi Ikebe wrote:
>  
>
>>Daniel-san,
>>GDB based approach seems not fit to our requirements. GDB(ptrace) based 
>>functions are basically need to be done when target process is stopping. 
>>From our experience, sometimes patches became to dozens to hundreds at 
>>one patching, and in this case GDB based approach cause target process's 
>>availability descent.
>>    
>>
>
>That's right, it does require the target process be stopped.  If it
>isn't stopped how do you know it isn't executing the same instruction
>you're currently patching?
>
>Even with hundreds of kilobytes of patch, I have trouble imagining this
>takes a substantial amount of time.
>  
>
Pannus patch does not require target process stop while loading(mapping)
patch module to target process memory,
but as you described, target process stopping is needed whenever check
EIP not to conflict, and overwrite jump assembly code.(This makes only
few milliseconds target process stopping. Even on hundreds, it only
takes dozens mill-seconds yet.)
Typically telecoms application needs soft real time, and has timeout.
This kind of framework can not stop target process so long(Should be
dozens milliseconds at worst).
We want not to stop target process whenever patch module is loading....
we want not to stop target process as possible as.

-- 
Takashi Ikebe
NTT Network Service Systems Laboratories
9-11, Midori-Cho 3-Chome Musashino-Shi,
Tokyo 180-8585 Japan
Tel : +81 422 59 4246, Fax : +81 422 60 4012
e-mail : ikebe.takashi@lab.ntt.co.jp



  reply	other threads:[~2005-04-18  5:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-17  3:47 [PATCH] i386 & x86_64: Live Patching Funcion on 2.6.11.7 Takashi Ikebe
2005-04-17  6:44 ` David S. Miller
2005-04-17 18:51   ` Daniel Jacobowitz
2005-04-17 20:32     ` David S. Miller
2005-04-18  1:41       ` Takashi Ikebe
2005-04-18  4:41         ` Daniel Jacobowitz
2005-04-18  5:20           ` Takashi Ikebe [this message]
2005-04-23 16:10   ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=426343AA.4090602@lab.ntt.co.jp \
    --to=ikebe.takashi@lab.ntt.co.jp \
    --cc=dan@debian.org \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox