jlebon at redhat dot com | 22 Apr 20:40 2014

[Bug dyninst/16795] utrace_p5.exp leaves stapdyn processes running

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

--- Comment #1 from Jonathan Lebon <jlebon at redhat dot com> ---
A similar issue also occurs with at_var_mark.exp, which causes the testsuite to
hang there. [Un]fortunately, it doesn't happen very often, so it's hard to
reproduce. I've found that it's more likely to happen after doing a clean
configure, make, make install (might have to do with caching perhaps?).

$ ps aux | grep stap
root     26910  0.2  0.2  85084  8108 pts/1    Ss+  13:58   0:00 stap -v
--runtime=dyninst ../../systemtap/testsuite/systemtap.base/at_var_mark.stp -c
/notnfs/jlebon/codebase/systemtap/install/bin/stap -e 'probe begin { exit() }'
root     27459  7.5  7.8 610172 306308 pts/1   Sl+  13:58   0:04
/notnfs/jlebon/codebase/systemtap/install/bin/stapdyn -c
/notnfs/jlebon/codebase/systemtap/install/bin/stap -e 'probe begin { exit() }'
/tmp/stapM3GKb1/stap_f8c1407b5661cce21695e03ffa4fc8ff_13290.so
root     27463  0.3  0.8 133200 32516 pts/1    t+   13:58   0:00
/notnfs/jlebon/codebase/systemtap/install/bin/stap -e probe begin { exit() }
root     27466  0.0  0.0      0     0 pts/1    Z+   13:58   0:00 [staprun]
<defunct>
[jlebon systemtap.base (master)]$ sudo gdb -p 27459
(gdb) bt
#0  0x00007f5e13ad4ecf in __GI_ppoll (fds=fds <at> entry=0x7ffffe6b10f0,
nfds=nfds <at> entry=1,
    timeout=<optimized out>, timeout <at> entry=0x7ffffe6b1100,
sigmask=sigmask <at> entry=0x7ffffe6b1110)
    at ../sysdeps/unix/sysv/linux/ppoll.c:56
#1  0x000000000040db72 in ppoll (__ss=0x7ffffe6b1110, __timeout=0x7ffffe6b1100,
__nfds=1,
    __fds=0x7ffffe6b10f0) at /usr/include/bits/poll2.h:77
(Continue reading)

jistone at redhat dot com | 21 Apr 22:36 2014

[Bug runtime/16861] New: probes aren't re-registered after module reload

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

            Bug ID: 16861
           Summary: probes aren't re-registered after module reload
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: jistone at redhat dot com

With emit_module_refresh, we can support probes in modules that weren't loaded
at the time stap started.  However, if a module is unloaded and then loaded
again, we miss the chance to register the probes anew.

For example, on a system not already using btrfs.ko:

$ stap -e 'probe module("btrfs").function("*_btrfs_fs").call {
println(ppfunc()) }' -c 'sudo sh -c "modprobe btrfs; modprobe -r btrfs;
modprobe btrfs; modprobe -r btrfs"'
init_btrfs_fs
exit_btrfs_fs

The init and exit are only noticed once, despite being loaded twice.

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
(Continue reading)

Naresh Kamboju | 19 Apr 20:53 2014

systemtap test suite compilation failed: include/linux/sysfs.h:449:2: argument 2 of 'kernfs_find_and_get' differ in signedness

Hi,

The systemtap test suite compilation failed with below error.

ARCH: arm
---------------

kernel version: 3.14.0-linaro-arndale
systemtap location: /usr/local/bin/stap
systemtap version: version 2.5/0.158, commit
release-2.4-489-ge5fb7aeea34b + changes
gcc location: /usr/bin/gcc
gcc version: gcc (Ubuntu/Linaro 4.8.1-10ubuntu8) 4.8.1

**** failed systemtap kernel-devel smoke test:

Makefile:622: Cannot use CONFIG_CC_STACKPROTECTOR_REGULAR:
-fstack-protector not supported by compiler
In file included from include/linux/kobject.h:21:0,
                 from include/linux/module.h:16,
                 from /usr/local/share/systemtap/runtime/linux/runtime.h:14,
                 from /usr/local/share/systemtap/runtime/runtime.h:24,
                 from
/tmp/stap5eHu9T/stap_bdd64b2c1a0e84441832fdc380015719_878_src.c:24:
include/linux/sysfs.h: In function 'sysfs_get_dirent':
include/linux/sysfs.h:449:2: error: pointer targets in passing
argument 2 of 'kernfs_find_and_get' differ in signedness
[-Werror=pointer-sign]
  return kernfs_find_and_get(parent, name);
  ^
(Continue reading)

Masami Hiramatsu | 17 Apr 10:16 2014
Picon

[PATCH -tip v9 00/26] kprobes: introduce NOKPROBE_SYMBOL, bugfixes and scalbility efforts

Hi,
Here is the version 9 of NOKPROBE_SYMBOL series, including
bugfixes. This updates some issues pointed in Steven's review
against v8 (Thank you!)

Blacklist improvements
======================
Currently, kprobes uses __kprobes annotation and internal symbol-
name based blacklist to prohibit probing on some functions, because
to probe those functions may cause an infinite recursive loop by
int3/debug exceptions.
However, current mechanisms have some problems especially from the
view point of maintaining code;
 - __kprobes is easy to confuse the function is
   used by kprobes, despite it just means "no kprobe
   on it".
 - __kprobes moves functions to different section
   this will be not good for cache optimization.
 - symbol-name based solution is not good at all,
   since the symbol name easily be changed, and
   we cannot notice it.
 - it doesn't support functions in modules at all.

Thus, I decided to introduce new NOKPROBE_SYMBOL macro for building
an integrated kprobe blacklist.

The new macro stores the address of the given symbols into
_kprobe_blacklist section, and initialize the blacklist based on the
address list at boottime.
This is also applied for modules. When loading a module, kprobes
(Continue reading)

jistone at redhat dot com | 15 Apr 19:20 2014

[Bug runtime/16844] New: Adapt to tracepoint API changes in 3.15

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

            Bug ID: 16844
           Summary: Adapt to tracepoint API changes in 3.15
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: jistone at redhat dot com

The basic register_trace_foo() interface is unchanged, but that inline now uses
the __tracepoint_##foo data symbol rather than a #foo string for the underlying
tracepoint_probe_register() call, and not many tracepoints actually declare
EXPORT_TRACEPOINT_SYMBOL[_GPL].

The new, apparently preferred, option is to use for_each_kernel_tracepoint() to
iterate the built-in tracepoints, and use the new tracepoint module notifier to
examine mod->tracepoints_ptrs[] for the rest.  Clients are also responsible for
unregistering tracepoints in modules that are unloading.

See also https://bugzilla.redhat.com/show_bug.cgi?id=1087623

--

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

(Continue reading)

Masatake YAMATO | 14 Apr 07:58 2014
Picon

[PATCH] Use pid2task when passing pid to task_execname(v2)

In v2 the case when pid2task returns NULL is handled.
Suggested by Josh Stone <jistone <at> redhat.com>.

Signed-off-by: Masatake YAMATO <yamato <at> redhat.com>
---
 tapset/linux/signal.stp | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/tapset/linux/signal.stp b/tapset/linux/signal.stp
index 48b7f5f..b529f5f 100644
--- a/tapset/linux/signal.stp
+++ b/tapset/linux/signal.stp
 <at>  <at>  -464,13 +464,15  <at>  <at>  probe signal.force_segv.return =
  *  <at> sig_name: A string representation of the signal
  *  <at> sig_pid: The PID of the process receiving the signal
  *  <at> pid_name: The name of the signal recipient
+ *  <at> task: A task handle to the signal recipient
  */
 probe signal.syskill = syscall.kill
 {
     name = "syskill"
     sig_name = _signal_name($sig)
     sig_pid = $pid
-    pid_name = task_execname($pid)
+    task = pid2task($pid)
+    pid_name = task? task_execname(task): ""
 }

 /**
 <at>  <at>  -488,6 +490,7  <at>  <at>  probe signal.syskill.return = syscall.kill.return
(Continue reading)

lberk at redhat dot com | 11 Apr 23:47 2014

[Bug runtime/16836] New: CFI expression underflow occurs during unwinding on some kernels

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

            Bug ID: 16836
           Summary: CFI expression underflow occurs during unwinding on
                    some kernels
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: lberk at redhat dot com

Running stap -e 'probe kernel.function("__run_hrtimer") { log ("hit!");
print_backtrace(); log("done"); exit(); }' on 3.13.6-100.fc19.x86_64,
3.13.7-100.fc19.x86_64 and 3.13.7-200.fc20.x86_64 causes a WARNING: DWARF
expression stack underflow in CFI (full output below)

WARNING: DWARF expression stack underflow in CFI
hit!
 0xffffffff81091ff0 : __run_hrtimer+0x0/0x1d0 [kernel]
 0xffffffff81092877 : hrtimer_interrupt+0xf7/0x240 [kernel]
 0xffffffff81042dc7 : local_apic_timer_interrupt+0x37/0x60 [kernel]
 0xffffffff8169203f : smp_apic_timer_interrupt+0x3f/0x60 [kernel]
 0xffffffff816909dd : apic_timer_interrupt+0x6d/0x80 [kernel]
done
hit!
 0xffffffff81091ff0 : __run_hrtimer+0x0/0x1d0 [kernel]
 0xffffffff81092877 : hrtimer_interrupt+0xf7/0x240 [kernel]
(Continue reading)

Masatake YAMATO | 11 Apr 09:15 2014
Picon

[PATCH] Use pid2task when passing pid to task_execname

Signed-off-by: Masatake YAMATO <yamato <at> redhat.com>
---
 tapset/linux/signal.stp | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tapset/linux/signal.stp b/tapset/linux/signal.stp
index 48b7f5f..0a7747e 100644
--- a/tapset/linux/signal.stp
+++ b/tapset/linux/signal.stp
 <at>  <at>  -470,7 +470,7  <at>  <at>  probe signal.syskill = syscall.kill
     name = "syskill"
     sig_name = _signal_name($sig)
     sig_pid = $pid
-    pid_name = task_execname($pid)
+    pid_name = task_execname(pid2task($pid))
 }

 /**
 <at>  <at>  -499,7 +499,7  <at>  <at>  probe signal.systkill = syscall.tkill
     name = "systkill"
     sig_name = _signal_name($sig)
     sig_pid = $pid
-    pid_name = task_execname($pid)
+    pid_name = task_execname(pid2task($pid))
 }

 /**
 <at>  <at>  -530,7 +530,7  <at>  <at>  probe signal.systgkill = syscall.tgkill
     name = "systgkill"
     sig_name = _signal_name($sig)
(Continue reading)

lberk at redhat dot com | 10 Apr 17:24 2014

[Bug translator/16829] New: Trigger STAPBM_VERBOSE=true automatically when -v's are specified with java probes

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

            Bug ID: 16829
           Summary: Trigger STAPBM_VERBOSE=true automatically when -v's
                    are specified with java probes
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: lberk at redhat dot com

The stapbm script (handling stap/byteman interaction and setup) has a verbosity
trigger of 'STAPBM_VERBOSE!=no'.  Currently the only way to trigger it, is to
manually set the environment variable when running a script, leaving users that
don't know about it with very little information when java probes aren't
inserted.  This could be avoided if, when enough -v's are triggered (say 2+),
we automatically set and passed the 'STAPBM_VERBOSE=geronimo' variable to
stapbm.  This is particularly useful in cases where stap has been built from
git and a commonly missed step is linking the appropriate helper .jar and .so

--

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

Victor Kamensky | 8 Apr 09:04 2014

[PATCH] systemtap: need to use kallsyms_lookup_funcptr with arm thumb2 kernel

Hi SystemTap maintainers, and ARM kernel gurus,

When SystemTap is used with Dave Long's uprobes series and kernel
compiled with CONFIG_THUMB2_KERNEL when SystemTap module attaches to
user-land executable kernel crashes with very weird traceback. 

The root case is very similar to issue discussed at [1] with lltng
and CONFIG_THUMB2_KERNEL - basically in SystemTap kernel module
support code kallsyms_lookup_name function is used to lookup symbol
and returned pointer is 2 or 4 bytes aligned; then pointer is casted
to function pointer and it is called. Because function pointer
call address does not have bit 0 set, CPU assumes that it jumps to
ARM code, but which is actually thumb2 opcodes, which in turns produces
very unexpected result, code jumps to some random place and crashes
there.

Proposed fix is very similar to one implemented at [1]. Basically
inside of SystemTap module support code it introduces
kallsyms_lookup_funcptr function which if called with 
CONFIG_THUMB2_KERNEL set bit 0 of returned function address or
returns result of kallsyms_lookup_name for all other case.

On [1] Dave Martin suggested to promote kallsyms_lookup_funcptr to
kernel headers, but it does not look it happened yet. Because it
affects many other than ARM architectures, personally, I am not sure
how to go about it. Never done it before ... I can try to do it 
with some guidance. If someone else can take it up, it will be
fine with me. It would be great to have solution in kernel headers.
Besides lttng and SystemTap, I guess, there could be other similar
cases.
(Continue reading)

Victor Kamensky | 8 Apr 07:23 2014

[PATCH] runtime: linux 3.14 porting: case when CONFIG_USER_NS not defined

Hi,

My systemtap tree is at a404e997732d88a148d822bab9ea413b01e5da41 and
I run it on ARMv7 3.14 based kernel. It looks like that there was
set of commits around kuid_t and kgid_t. However it does look it is
enough to cover all possible cases. In my case CONFIG_USER_NS is not 
set but kernel is 3.14 with CONFIG_UIDGID_STRICT_TYPE_CHECKS removal
commit present.

Pass 1: parsed user script and 100 library script(s) using 20524virt/16336res/1728shr/15264data kb, in
550usr/30sys/775real ms.
Pass 2: analyzed script: 5 probe(s), 8 function(s), 3 embed(s), 2 global(s) using
21996virt/18572res/2624shr/16736data kb, in 1270usr/960sys/2640real ms.
Pass 3: translated to C into "/tmp/stapKpOeoW/stap_ab952db703452530b1d473c8f05f8f6d_6448_src.c"
using 21996virt/18800res/2852shr/16736data kb, in 50usr/280sys/324real ms.
In file included from /home/root/systemtap/systemtap-20140405/share/systemtap/runtime/linux/task_finder.c:17:0,
                 from /home/root/systemtap/systemtap-20140405/share/systemtap/runtime/linux/runtime.h:206,
                 from /home/root/systemtap/systemtap-20140405/share/systemtap/runtime/runtime.h:24,
                 from /tmp/stapKpOeoW/stap_ab952db703452530b1d473c8f05f8f6d_6448_src.c:24:
/home/root/systemtap/systemtap-20140405/share/systemtap/runtime/linux/task_finder2.c: In
function
'__stp_utrace_attach_match_filename':
/home/root/systemtap/systemtap-20140405/share/systemtap/runtime/linux/task_finder2.c:813:11:
error: incompatible types when assigning to type 'uid_t' from type 'kuid_t'
  tsk_euid = task_euid(tsk);
           ^
/home/root/systemtap/systemtap-20140405/share/systemtap/runtime/linux/task_finder2.c: In
function
'stap_start_task_finder':
/home/root/systemtap/systemtap-20140405/share/systemtap/runtime/linux/task_finder2.c:1703:12:
(Continue reading)


Gmane