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)

Timo Juhani Lindfors | 7 Apr 14:21 2014
Picon
Picon

cyclic build dependency libvirt->systemtap->libvirt?

Hi,

systemtap 2.4 seems to use libvirt headers during build. In debian
libvirt also uses systemtap sdt.h during build. Is this intentional or
should we try to mitigate this somehow? Cyclic build dependencies are
problematic e.g. when porting software to new architectures or compilers
(such as clang).

-Timo

jlebon at redhat dot com | 3 Apr 21:22 2014

[Bug runtime/16806] New: kernel crash during repeated module insertion

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

            Bug ID: 16806
           Summary: kernel crash during repeated module insertion
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: jlebon at redhat dot com

This crash sompetimes occurs during the testsuite run of
unprivileged_myproc.exp under f19. I've been able to reproduce it more directly
as follow (files are based on loop.c and libloop.c from
testsuite/systemtap.unprivileged):

$ cat loop2.c
#include <pthread.h>
#include <unistd.h>
#include "sys/sdt.h"

extern int libloopfunc (void);

/* Thread entry point */
void *bar (void *b) {
  int i;
  int *j = (int *)b;
  for (i = 0; i < 10; ++i)
(Continue reading)

jistone at redhat dot com | 2 Apr 23:50 2014

[Bug translator/16802] New: Consider supporting terminal-colors.d

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

            Bug ID: 16802
           Summary: Consider supporting terminal-colors.d
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: jistone at redhat dot com

There is a new scheme in util-linux to specify preferences for coloring command
output.  They've invited other projects to follow along.  See:
http://man7.org/linux/man-pages/man5/terminal-colors.d.5.html
http://karelzak.blogspot.com/2014/04/terminal-colorsd.html

--

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


Gmane