This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH 1/1] x86: fix text_poke
- From: Masami Hiramatsu <mhiramat at redhat dot com>
- To: Jeremy Fitzhardinge <jeremy at goop dot org>
- Cc: Mathieu Desnoyers <mathieu dot desnoyers at polymtl dot ca>, Linus Torvalds <torvalds at linux-foundation dot org>, "H. Peter Anvin" <hpa at zytor dot com>, Andi Kleen <andi at firstfloor dot org>, Ingo Molnar <mingo at elte dot hu>, Jiri Slaby <jirislaby at gmail dot com>, David Miller <davem at davemloft dot net>, zdenek dot kabelac at gmail dot com, rjw at sisk dot pl, paulmck at linux dot vnet dot ibm dot com, akpm at linux-foundation dot org, linux-ext4 at vger dot kernel dot org, herbert at gondor dot apana dot org dot au, penberg at cs dot helsinki dot fi, clameter at sgi dot com, linux-kernel at vger dot kernel dot org, pageexec at freemail dot hu, "Frank Ch. Eigler" <fche at redhat dot com>, systemtap at sources dot redhat dot com
- Date: Fri, 25 Apr 2008 19:34:24 -0400
- Subject: Re: [PATCH 1/1] x86: fix text_poke
- References: <20080425163035.GE9503@Krystal> <481209F2.4050908@zytor.com> <20080425170929.GA16180@Krystal> <20080425183748.GB16180@Krystal> <48123C9B.9020306@zytor.com> <20080425203717.GB25950@Krystal> <481241DC.3070601@zytor.com> <alpine.LFD.1.10.0804251349510.2779@woody.linux-foundation.org> <20080425211205.GC25950@Krystal> <alpine.LFD.1.10.0804251456410.2779@woody.linux-foundation.org> <20080425230028.GC31226@Krystal> <481265B7.9040505@goop.org>
Jeremy Fitzhardinge wrote:
> Mathieu Desnoyers wrote:
>> This idea has been considered a few years ago at OLS in the tracing BOF
>> if I remember well. The results were this : First, there is no way to
>> guarantee that no code path, nor any return address from any function,
>> interrupt, sleeping thread, will return to the "old" version of the
>> function. Nor is it possible to determine when a quiescent state is
>> reached. Therefore, we couldn't see how we can do the teardown.
>>
>
> Does that matter? The new function is semantically identical to the old
> one, and the old code will remain in place. If there's still users in
> the old function it may take a while for them to get flushed out (and
> won't be traced in the meantime), but you have to expect some missed
> events if you're shoving any kind of dynamic marker into the code. The
> main problem is if there's something still depending on the first 5
> bytes of the function (most likely if there's a loop head somewhere near
> the top of the function).
I think we have to ensure no threads sleeping or being interrupted on
the function when removing new function. How would you check it?
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com