William Cohen | 17 Dec 20:59 2014
Picon

Example SystemTap script to provide information about what is forking processes on the system

Hi All,

I was talking with some other people at a local linux user group meeting last week and the suggestion to have a
script that provided some information about what was forking processes came up.  Today I coded up the
script.  Any suggestions for improvement on this before I add it to the examples?

-Will
#! /usr/bin/env stap
# Copyright (C) 2014 Red Hat, Inc.
# Written by William Cohen <wcohen <at> redhat.com>
#
#   spawn_seeker provides a breakdown of which processes and children
#   are spawning new processes.  To provide better information about
#   short-lived process when a child exits the child's spawns are
#   added to its parent.
#
# control-c to exit data collection

global pid_name, fork_by_pid, fork_by_name, fork_count

probe kprocess.create {
  pid_name[pid()] = execname()
  fork_by_pid[pid()]++
  fork_by_name[execname()]++
  fork_count++
}

probe kprocess.exit {
(Continue reading)

mcermak at redhat dot com | 15 Dec 12:43 2014

[Bug tapsets/17714] New: poll.c syscall testcase

https://sourceware.org/bugzilla/show_bug.cgi?id=17714

            Bug ID: 17714
           Summary: poll.c syscall testcase
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com

Created attachment 8015
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8015&action=edit
proposed patch

Two issues wrt. syscall.epoll_pwait and related testcase:

1) in the syscalls.stp tapset, $events and $sigmask pointers from
syscall.epoll_pwait have wrong values on s390 31-on-64. Following update fixes
the issue for me and seems to test fine "everywhere".

=======
--- a/tapset/linux/syscalls.stp
+++ b/tapset/linux/syscalls.stp
 <at>  <at>  -857,14 +857,14  <at>  <at>  probe syscall.epoll_pwait =
kernel.function("compat_sys_epoll_pwait").call ?,
 {
        name = "epoll_pwait"
(Continue reading)

ledest at gmail dot com | 14 Dec 13:35 2014

[Bug server/17710] New: stap-report script contains bashisms

https://sourceware.org/bugzilla/show_bug.cgi?id=17710

            Bug ID: 17710
           Summary: stap-report script contains bashisms
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: server
          Assignee: systemtap at sourceware dot org
          Reporter: ledest at gmail dot com

Created attachment 8011
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8011&action=edit
fix bashisms in stap-report script

stap-report shell script contains bashisms that may be unsupported in some
POSIX-complete shells.

--

-- 
You are receiving this mail because:
You are the assignee for the bug.

hai wu | 14 Dec 05:35 2014
Picon

[PATCH] filename in tapset nfs.proc.open and nfs.proc.release

tapset nfs.proc.open and nfs.proc.release in nfs_proc.stp only records
file's basename, which is not helpful when we use it to monitor NFS
file access activities.

The following patch would allow us to be able to see the full path for
NFS file, along with its NFS mount information.

diff --git a/tapset/linux/nfs_proc.stp b/tapset/linux/nfs_proc.stp
index 1339aee..5a804e4 100644
--- a/tapset/linux/nfs_proc.stp
+++ b/tapset/linux/nfs_proc.stp
 <at>  <at>  -1658,7 +1658,7  <at>  <at>  probe nfs.proc.open = kernel.function("nfs_open") !,
        prot = get_prot_from_client(client)
        version = __nfs_version($inode)

-       filename = __file_filename($filp)
+  filename = task_dentry_path(task_current(), $filp->f_dentry, $filp->f_vfsmnt)
        flag = $filp->f_flags
        mode = $filp->f_mode

 <at>  <at>  -1693,7 +1693,7  <at>  <at>  probe nfs.proc.release = kernel.function("nfs_release") !,
        prot = get_prot_from_client(client)
        version = __nfs_version($inode)

-       filename = __file_filename($filp)
+  filename = task_dentry_path(task_current(), $filp->f_dentry, $filp->f_vfsmnt)
        flag = $filp->f_flags
        mode = $filp->f_mode

(Continue reading)

mcermak at redhat dot com | 12 Dec 18:44 2014

[Bug runtime/17706] New: user string copy fault on s390 in 31-on-64 mode

https://sourceware.org/bugzilla/show_bug.cgi?id=17706

            Bug ID: 17706
           Summary: user string copy fault on s390 in 31-on-64 mode
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com

I see following user string copy fault on s390 in 31-on-64 mode. Note that
strace seems to have similar issue:

 7.1 S s390x # cat openclose.c 
/* COVERAGE: open openat close creat */
#define _GNU_SOURCE
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdlib.h>
#include <unistd.h>

int main()
{
  int fd1;

(Continue reading)

zhuo at bitoasis dot com | 11 Dec 03:58 2014

[Bug runtime/17696] New: Systemtap fails to find kernel tracepoints when kernel is built in a separate directory from source tree

https://sourceware.org/bugzilla/show_bug.cgi?id=17696

            Bug ID: 17696
           Summary: Systemtap fails to find kernel tracepoints when kernel
                    is built in a separate directory from source tree
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: zhuo at bitoasis dot com

* A:

When kernel is built in a separate directory from the kernel source tree:

1) before building:

export BUILDDIR=/a/separate/path/
export KBUILD_OUTPUT=${BUILDDIR}/build

2) after building and installing:

   /lib/modules/`uname -r`/build links to /a/separate/path/
   /lib/modules/`uname -r`/source links to /kernel/source/tree/

Under this situation, stap -L 'kernel.trace("*")' lists nothing.

(Continue reading)

mcermak at redhat dot com | 10 Dec 18:45 2014

[Bug runtime/17695] New: nfs3_proc_read_setup: unable to find local 'data'

https://sourceware.org/bugzilla/show_bug.cgi?id=17695

            Bug ID: 17695
           Summary: nfs3_proc_read_setup: unable to find local 'data'
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com

Using git stap (957812a) following issue arises:

 7.1 S x86_64 # uname -r 
3.10.0-215.el7.x86_64
 7.1 S x86_64 # stap -p2 -e 'probe nfs.proc.read_setup{println(prot)}'
semantic error: unable to find local 'data', [man error::dwarf] dieoffset
0x4a603 in nfsv3, near pc 0x10130 in nfs3_proc_read_setup fs/nfs/nfs3proc.c
(alternatives: $hdr, $msg)): identifier '$data' at
/usr/share/systemtap/tapset/linux/nfs_proc.stp:754:59
        source:         inode =  <at> defined($data->header) ? $data->header->inode
: $data->inode

 ^

Pass 2: analysis failed.  [man error::pass2]
 7.1 S x86_64 # 

(Continue reading)

dsmith at redhat dot com | 9 Dec 17:55 2014

[Bug tapsets/17690] New: probe nfs.proc3.rename no longer valid

https://sourceware.org/bugzilla/show_bug.cgi?id=17690

            Bug ID: 17690
           Summary: probe nfs.proc3.rename no longer valid
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com

Under newer kernels, the nfs.proc3.rename probe is broken:

====
# stap -ve 'probe nfs.proc3.rename {}'
Pass 1: parsed user script and 109 library script(s) using
216584virt/32080res/2984shr/29532data kb, in 210usr/50sys/255real ms.
semantic error: while resolving probe point: identifier 'nfs' at <input>:1:7
        source: probe nfs.proc3.rename {}
====

This is because the kernel switched to an asynchronous rename method then
finally removed the old code that systemtap probed in this commit:

====
commit 33912be816d96e204ed7a93690552daa39c08ea9                                 
Author: Jeff Layton <jlayton <at> redhat.com>                                        
Date:   Mon Mar 17 07:06:57 2014 -0400                                          
(Continue reading)

dsmith at redhat dot com | 8 Dec 22:53 2014

[Bug tapsets/17688] New: probe nfs.fop.aio_read no longer valid

https://sourceware.org/bugzilla/show_bug.cgi?id=17688

            Bug ID: 17688
           Summary: probe nfs.fop.aio_read no longer valid
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com

In tapset/linux/nfs.stp, we've got:

====
probe nfs.fop.aio_read = kernel.function ("nfs_file_read") !,
                         module("nfs").function("nfs_file_read")
====

The following kernel commit (first present in 3.16) makes the above probe
invalid:

<https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/nfs/file.c?id=3aa2d199f8eb8149a88005e88736d583cbc39d31>

Here's the first part of that patch:

====
From 3aa2d199f8eb8149a88005e88736d583cbc39d31 Mon Sep 17 00:00:00 2001
From: Al Viro <viro <at> zeniv.linux.org.uk>
(Continue reading)

KDr2 | 8 Dec 14:36 2014
Picon

SystemTap fails to find kernel tracepoints

I got a problem with stap, would anyone help?

OVERVIEW:
1) I use debian sid
2) All pkgs needed by stap are installed, stap-prep exit with code 0
3) kernel is compiled with tracepoints support
4) stap can probe kernel.function("*"), syscall.*, process("a.out").function
5) The problem:
   stap can not probe kernel.trace("*")

DETAILS:
1)
root <at> Debian64-QEMU:~# more /etc/issue
Debian GNU/Linux sid \n \l

2)
root <at> Debian64-QEMU:~# stap-prep
root <at> Debian64-QEMU:~# echo $?
0
root <at> Debian64-QEMU:~# dpkg -l|egrep "linux-(image|headers)"
ii  linux-headers-3.16.0-4-amd64     3.16.7-2                    amd64
       Header files for Linux 3.16.0-4-amd64
ii  linux-headers-3.16.0-4-common    3.16.7-2                    amd64
       Common header files for Linux 3.16.0-4
ii  linux-headers-amd64              3.16+63                     amd64
       Header files for Linux amd64 configuration (meta-package)
ii  linux-image-3.16.0-4-amd64       3.16.7-2                    amd64
       Linux 3.16 for 64-bit PCs
ii  linux-image-3.16.0-4-amd64-dbg   3.16.7-2                    amd64
       Debugging symbols for Linux 3.16.0-4-amd64
(Continue reading)

Sergey.Klyaus@Tune-IT.Ru | 28 Nov 10:21 2014

[Bug uprobes/17660] New: <at> perf wont work with uprobes

https://sourceware.org/bugzilla/show_bug.cgi?id=17660

            Bug ID: 17660
           Summary:  <at> perf wont work with uprobes
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: uprobes
          Assignee: systemtap at sourceware dot org
          Reporter: Sergey.Klyaus <at> Tune-IT.Ru

Hello.

Debian 7
SystemTap 2.6
Linux kernels 3.12.6 and 3.18-rc6

I found that new versions of SystemTap support  <at> perf, so I wanted to try it.
Here are the test script:

$ stap -v -e '
probe perf.hw.instructions
    .process("/bin/bash")
    .counter("insns") { } 

probe process("/bin/bash").function("cd_builtin")  { 
    printf(" insns = %d\n",  <at> perf("insns"));
}' 
(Continue reading)


Gmane