Frank Ch. Eigler | 1 Nov 17:13 2005
Picon

version-sensitive ifdef

Hi -

I'm committing code for PR 1425.  It adds a baby preprocessor to the
parser, to allow a script to include or exclude tokens based on the
target kernel version.  For now, the version string comparison is done
with a routine from rpmlib, which is henceforth a prerequisite.  From
the amended man page:

   A  simple conditional preprocessing stage is run as a part of parsing.
   The general form is similar to the cond ? exp1 : exp2  ternary  opera-
   tor:
          %( CONDITION %? TRUE-TOKENS %)
          %( CONDITION %? TRUE-TOKENS %: FALSE-TOKENS %)
   The  CONDITION is a very limited expression consisting of three parts.
   The first part is the identifier kernel_vr or kernel_v to refer to the
   kernel   version   number,   with  ("2.6.13-1.322FC3smp")  or  without
   ("2.6.13") the release code suffix.  The second part is one of the six
   standard  numeric  comparison operators <, <=, ==, !=, >, and >=.  The
   third part is a string literal that contains an RPM-style  version-re-
   lease  value.  The condition is deemed satisfied if the version of the
   target kernel (as optionally overridden by the -r option) compares  to
   the  given version string.  The comparison is performed by the RPM li-
   brary function rpmvercmp.  The TRUE-TOKENS and FALSE-TOKENS  are  zero
   or  more general parser tokens (possibly including nested preprocessor
   conditionals), and are pasted into the input stream if  the  condition
   is true or false.  For example, the following code induces a parse er-
   ror unless the target kernel version is newer than 2.6.5:
          %( kernel_v <= "2.6.5" %? **ERROR** %) # invalid token sequence
   The following code might adapt to hypothetical kernel version drift:
          probe kernel.function (
(Continue reading)

Hien Nguyen | 1 Nov 17:57 2005
Picon

[PATCH] Systemtap ppc64 runtime

This patch implements the _stp_stack_print() function for the ppc64 
runtime. In order for this implementation to work, the kernel needs to 
be configured with CONFIG_KALLSYMS_ALL=y.

Some background. we use the kallsyms_lookup_name() to get access to some
of the unexported functions in the kernel. Under ppc64, the 
kallsysms_lookup_name(".funcname") gives us the function entry address, 
but the kallsyms_lookup_name("funcname") gives us the function 
descriptor. We want the latter case. See the reference
http://www.linuxbase.org/spec/ELF/ppc64/PPC-elf64abi-1.7.html#FUNC-DES

The patch should apply to the snapshoot systemtap-20052910.tar.bz2.

Hien.

--- src-20051029/runtime/runtime.h	2005-10-28 15:49:28.000000000 -0700
+++ src-20051029.works/runtime/runtime.h	2005-10-31 10:18:18.000000000 -0800
 <at>  <at>  -70,6 +70,10  <at>  <at> 
 					    unsigned long *symbolsize,
 					    unsigned long *offset,
 					    char **modname, char *namebuf);
+#if defined (__powerpc64__)
+static int (*_stp_validate_sp)(unsigned long sp, struct task_struct *p,
+				unsigned long nbytes);
+#endif

 /* TEST_MODE is always defined by systemtap */
 #ifdef TEST_MODE
 <at>  <at>  -131,8 +135,21  <at>  <at> 
 #endif
(Continue reading)

Masami Hiramatsu | 2 Nov 02:14 2005
Picon

[Fwd: [RFC][PATCH 0/3]Djprobe (Direct Jump Probe) for 2.6.14-rc5-mm1]

Hi,

I posted latest djprobe patch to Linux-kernel ML.
But it seems that it was rejected by spam-filter on this ML...
So I send it again.

-------- Original Message --------
Subject: [RFC][PATCH 0/3]Djprobe (Direct Jump Probe) for 2.6.14-rc5-mm1
Date: Mon, 31 Oct 2005 20:04:04 +0900
From: Masami Hiramatsu <hiramatu <at> sdl.hitachi.co.jp>
To: linux-kernel <at> vger.kernel.org
CC: Satoshi Oshima <soshima <at> redhat.com>, Hideo Aoki <haoki <at> redhat.com>,  Yumiko Sugita
<sugita <at> sdl.hitachi.co.jp>,  noboru.obata.ar <at> hitachi.com,  systemtap <at> sources.redhat.com

Hello,

I would like to propose djprobe (Direct Jump Probe) for low overhead
probing.
The djprobe is useful for the performance analysis function and the
kernel flight-recording function which constantly traces events in
the kernel. Because we should make their influence on performance as
small as possible.
Djprobe is a kind of probes in kernel like kprobes.
 It has some features:
- Jump instruction based probe. This is so fast.
- Non interruption.
- Safely code insertion on SMP.
- Lockless probe after registered.
I attached detailed document of djprobe to this mail. If you need
more information, please see it.
(Continue reading)

Masami Hiramatsu | 2 Nov 02:51 2005
Picon

[Fwd: [RFC][PATCH 1/3]Djprobe (Direct Jump Probe) for 2.6.14-rc5-mm1]

Hi,

Here is the second mail which I posted to LKML.

---
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: hiramatu <at> sdl.hitachi.co.jp

-------- Original Message --------
Subject: [RFC][PATCH 1/3]Djprobe (Direct Jump Probe) for 2.6.14-rc5-mm1
Date: Mon, 31 Oct 2005 20:07:45 +0900
From: Masami Hiramatsu <hiramatu <at> sdl.hitachi.co.jp>
To: linux-kernel <at> vger.kernel.org
CC: Satoshi Oshima <soshima <at> redhat.com>, Hideo Aoki <haoki <at> redhat.com>,        Yumiko Sugita
<sugita <at> sdl.hitachi.co.jp>, noboru.obata.ar <at> hitachi.com,        systemtap <at> sources.redhat.com
References: <4365FA24.7030207 <at> sdl.hitachi.co.jp>

Hi,

This patch enables get_insn_slot() to handle slots that have
different size.
The djprobe requires this patch to work it on the machines which
support "NX bit".

---
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
(Continue reading)

Masami Hiramatsu | 2 Nov 02:52 2005
Picon

[Fwd: [RFC][PATCH 2/3]Djprobe (Direct Jump Probe) for 2.6.14-rc5-mm1]

Hi,

Here is the third mail which I posted to LKML.

---
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: hiramatu <at> sdl.hitachi.co.jp

-------- Original Message --------
Subject: [RFC][PATCH 2/3]Djprobe (Direct Jump Probe) for 2.6.14-rc5-mm1
Date: Mon, 31 Oct 2005 20:08:50 +0900
From: Masami Hiramatsu <hiramatu <at> sdl.hitachi.co.jp>
To: linux-kernel <at> vger.kernel.org
CC: Satoshi Oshima <soshima <at> redhat.com>, Hideo Aoki <haoki <at> redhat.com>,        Yumiko Sugita
<sugita <at> sdl.hitachi.co.jp>, noboru.obata.ar <at> hitachi.com,        systemtap <at> sources.redhat.com
References: <4365FA24.7030207 <at> sdl.hitachi.co.jp> <4365FB01.2070505 <at> sdl.hitachi.co.jp>

Hi,

This patch is the architecture independant part of djprobe.
The djprobe would replace the kernel codes (target codes) to insert
a jump instruction.
But the target codes may be run by other processors. So the djprobe
should ensure that no other processor is running on the target codes.
First, the djprobe makes a bypass route from a copy of the target codes.
And it inserts kprobes at the top address of the target codes. Thus
other processors can detour the target codes by using the bypass route.
Next, the djprobe runs works on other processors and waits until all
(Continue reading)

Masami Hiramatsu | 2 Nov 02:54 2005
Picon

[Fwd: [RFC][PATCH 3/3]Djprobe (Direct Jump Probe) for 2.6.14-rc5-mm1]

Hi,

Here is the forth mail which I posted to LKML.

-------- Original Message --------
Subject: [RFC][PATCH 3/3]Djprobe (Direct Jump Probe) for 2.6.14-rc5-mm1
Date: Mon, 31 Oct 2005 20:10:50 +0900
From: Masami Hiramatsu <hiramatu <at> sdl.hitachi.co.jp>
To: linux-kernel <at> vger.kernel.org
CC: Satoshi Oshima <soshima <at> redhat.com>, Hideo Aoki <haoki <at> redhat.com>,        Yumiko Sugita
<sugita <at> sdl.hitachi.co.jp>, noboru.obata.ar <at> hitachi.com,        systemtap <at> sources.redhat.com
References: <4365FA24.7030207 <at> sdl.hitachi.co.jp> <4365FB01.2070505 <at> sdl.hitachi.co.jp> <4365FB42.7040502 <at> sdl.hitachi.co.jp>

Hi,

This patch is the i386 architecture dependent codes of djprobe.
I heard that we need to synchronize caches of each processor if we
execute self modifying on i386.
So, this patch synchronize caches by using CPUID and smp_call_function.

---
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: hiramatu <at> sdl.hitachi.co.jp

Signed-off-by: Masami Hiramatsu <hiramatu <at> sdl.hitachi.co.jp>

 arch/i386/Kconfig               |    8 +
 arch/i386/kernel/Makefile       |    1
(Continue reading)

Martin Hunt | 2 Nov 18:25 2005
Picon

Re: [PATCH] Systemtap ppc64 runtime

On Tue, 2005-11-01 at 08:57 -0800, Hien Nguyen wrote:
> This patch implements the _stp_stack_print() function for the ppc64 
> runtime. In order for this implementation to work, the kernel needs to 
> be configured with CONFIG_KALLSYMS_ALL=y.

Looks reasonable.  Go ahead and check it in.

Martin

Kevin Stafford | 3 Nov 01:26 2005
Picon

Minutes of SystemTap Conference Call, Oct 27, 2005

Minutes of SystemTap Conference Call, Oct 27, 2005

Participants:
IBM:
        Ananth Mavinakayanahalli (mananth <at> in.ibm.com -- Boston)
        Jim Keniston (jkenisto <at> us.ibm.com -- Beaverton)
        Kevin Stafford (kevinrs <at> us.ibm.com -- Beaverton)
        Hien Nguyen (nguyhien <at> us.ibm.com -- Beaverton)
        Prasanna Panchamukhi (prasanna <at> in.ibm.com -- Bangalore)
Red Hat:
        Elena Zannoni (ezannoni <at> redhat.com -- Boston)
        Graydon Hoare (graydon <at> redhat.com -- Vancouver)
        Martin Hunt (hunt <at> redhat.com -- Seattle)
        Frank Eigler (fche <at> redhat.com -- Toronto)
        Will Cohen (wcohen <at> redhat.com -- Raleigh)
Intel:
        Josh Stone (joshua.i.stone <at> intel.com -- Santa Clara)
        Anil Keshavamurthy (anil.s.keshavamurthy <at> intel.com -- Hillsboro)
Hitachi:
        Satoshi Oshima (soshima <at> redhat.com)

Actions Required (ARs):
 >From 5/19/05:

23. Jim, Martin: Ensure that the runtime's stack-trace feature works
    appropriately when there are return probes in the call stack.
    [Update: Martin is working on this.  Jim will prototype an improvement
    whereby the saved IP is updated before the handler is called.]

 >From 6/9/05:
(Continue reading)

Guang Lei Li | 3 Nov 15:01 2005
Picon

return probe not executed on SMP system

Hi,

  I met some difficulties when dealing with the return probe on a 
multi-processor system(Power5 System, 4 CPU).

  This is the stap script I used:

global counter

function info()
%{
  struct task_struct *cur = current;
  _stp_printf("\n|%ld|%ld|%ld|%u|", cur->pid, cur->tgid, 
cur->thread_info->cpu);
%}

probe kernel.function("sys_read")
{
  if(pid() == target())
  {
    counter--
    info()
    log("pid:".string(pid())." target:".string(target())."entry")
  }
}

probe kernel.function("sys_read").return
{
  if(pid() == target())
  {
(Continue reading)

Hien Nguyen | 3 Nov 17:58 2005
Picon

Re: return probe not executed on SMP system

You probably run out out kretprobe instances. When the return probe runs 
out kretprobe instances (maxactive), it just skips and increase an 
internal counter "nmissed".

Systemtap does not have the interface to change kretprobe->maxactive (in 
this case increase the maxactive would help) or examine kretprobe->nmissed.

Hien.

Guang Lei Li wrote:

>Hi,
>
>  I met some difficulties when dealing with the return probe on a 
>multi-processor system(Power5 System, 4 CPU).
>
>  This is the stap script I used:
>
>global counter
>
>function info()
>%{
>  struct task_struct *cur = current;
>  _stp_printf("\n|%ld|%ld|%ld|%u|", cur->pid, cur->tgid, 
>cur->thread_info->cpu);
>%}
>
>probe kernel.function("sys_read")
>{
>  if(pid() == target())
(Continue reading)


Gmane