gmane.linux.systemtap

Re: systemtap broken by USER_NS for now

David Smith — 2013-05-22T21:40:40

Hmm, thanks for finding this and developing the patch. The tricky part
here will be supporting 3.9 without breaking some of the earliest
kernels we support (like RHEL4's 2.6.9).

I'll look into your patch. I'm also wondering if some of the procfs
fixes I just put in will work with CONFIG_UIDGID_STRICT_TYPE_CHECKS.

I'll send out an update when I've figured something out.

[PATCH] fix aggregate stats in mutex-contention example

Peter Feiner — 2013-05-22T20:04:27

Stats that were supposed to be collected per FUTEX_WAIT call site were being
collected per mutex init stack. So, in the "aggregate stats" section of the
report, you'd see a bunch of stacks with pthread_mutex_init at the top ... which
was very confusing because a futex isn't contended when it's created :-)
---
 .../process/mutex-contention.stp                   |    6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/testsuite/systemtap.examples/process/mutex-contention.stp b/testsuite/systemtap.examples/process/mutex-contention.stp
index 4bd0486..eec4b4c 100755
--- a/testsuite/systemtap.examples/process/mutex-contention.stp
+++ b/testsuite/systemtap.examples/process/mutex-contention.stp
< at >< at > -65,26 +65,22 < at >< at > probe syscall.futex.return {
   if (keep_stats) {
     mutex_contention[$uaddr] <<< elapsed
     stack = sprint_ubacktrace()
+    mutex_cont_stack[stack] <<< elapsed
     mutex_last_cont_stack[$uaddr] = stack
     if ($uaddr in mutex_init_stack) {
       if (verbose) {
         printf("c

[Bug dyninst/15513] add a "runtime" preprocessor conditional

dsmith at redhat dot com — 2013-05-22T15:52:15

http://sourceware.org/bugzilla/show_bug.cgi?id=15513

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from David Smith <dsmith at redhat dot com> 2013-05-22 15:52:15 UTC ---
Fixed in commit d9677d7. The new 'runtime' preprocessor will have the value of
'kernel' or 'dyninst'.

Re: Re: systemtap 2.2.1 installcheck => kernel BUG at .. kprobes.c:707

Frank Ch. Eigler — 2013-05-22T14:21:49

Hi, Masami -


Thanks for looking into it!


I don't quite understand.  In systemtap, as per runtime/transport/transport.c,
we use a notifier priority of 1 for the _stp_module_notifier, so that we get
notified after the kprobes_module_callback.  I believe this behavior matches
ftrace.


- FChE

systemtap broken by USER_NS for now

Alexander Y. Fomichev — 2013-05-22T14:00:06

Hi

for now user_ns unconditionally requires
CONFIG_UIDGID_STRICT_TYPE_CHECKS and the latter in turn breaks things
this way:

typedef struct {
        uid_t val;
} kuid_t;

and so:

stap # ./probe.stp
In file included from /usr/share/systemtap/runtime/linux/task_finder.c:17:0,
                 from /usr/share/systemtap/runtime/linux/runtime.h:188,
                 from /usr/share/systemtap/runtime/runtime.h:24,
                 from
/tmp/.private/root/stap7M7WmA/stap_6ce999ddb8d32c70dcbe287153f6957f_16537_src.c:22:
/usr/share/systemtap/runtime/linux/task_finder2.c: In function
'__stp_utrace_attach_match_filename':
/usr/share/systemtap/runtime/linux/task_finder2.c:816:11: error:
incompatible types when assigning to type 'uid_t' from type 'kuid_t'
  tsk_euid = task_euid(tsk);
           ^
.....................................................................

It seems like fix is straightforward - just use from_kuid_munged to
get euid if CONFIG_UIDGID_STRICT_TYPE_CHECKS is defined. (really it
always works on la

Re: [PATCH 2/2] [BUGFIX] kprobes/mips: Fix to check double free of insn slot

Ralf Baechle — 2013-05-22T10:37:30

Thanks, applied.

  Ralf

[PATCH 2/2] [BUGFIX] kprobes/mips: Fix to check double free of insn slot

Masami Hiramatsu — 2013-05-22T09:34:13

Fix to check double free of insn_slot at arch_remove_kprobe
as other arches do.

Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt< at >hitachi.com>
Cc: Ralf Baechle <ralf< at >linux-mips.org>
Cc: David Daney <ddaney< at >caviumnetworks.com>
Cc: Maneesh Soni <manesoni< at >cisco.com>
Cc: Victor Kamensky <kamensky< at >cisco.com>
Cc: linux-mips< at >linux-mips.org
---
 arch/mips/kernel/kprobes.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/mips/kernel/kprobes.c b/arch/mips/kernel/kprobes.c
index 12bc4eb..1f8187a 100644
--- a/arch/mips/kernel/kprobes.c
+++ b/arch/mips/kernel/kprobes.c
< at >< at > -207,7 +207,10 < at >< at > void __kprobes arch_disarm_kprobe(struct kprobe *p)
 
 void __kprobes arch_remove_kprobe(struct kprobe *p)
 {
-free_insn_slot(p->ainsn.insn, 0);
+if (p->ainsn.insn) {
+free_insn_slot(p->ainsn.insn, 0);
+p->ainsn.insn = NULL;
+}
 }
 
 static void save_previous_kprobe(struct kprobe_ctlblk *kcb)

[PATCH 1/2] [BUGFIX] kprobes: Fix to free gone and unused optprobes

Masami Hiramatsu — 2013-05-22T09:34:09

Fix to free gone and unused optprobes. This bug will
cause a kernel panic if the user reuse the killed and
unused probe.

Reported: http://sourceware.org/ml/systemtap/2013-q2/msg00142.html

In the normal path, an optprobe on an init function is
unregistered when a module goes live.

unregister_kprobe(kp)
 -> __unregister_kprobe_top
   ->__disable_kprobe
     ->disarm_kprobe(ap == op)
       ->__disarm_kprobe
        ->unoptimize_kprobe : the op is queued
                              on unoptimizing_list
and do nothing in __unregister_kprobe_bottom

After a while (usually wait 5 jiffies), kprobe_optimizer
runs to unoptimize and free optprobe.

kprobe_optimizer
 ->do_unoptimize_kprobes
   ->arch_unoptimize_kprobes : moved to free_list
 ->do_free_cleaned_kprobes
   ->hlist_del: the op is removed
   ->free_aggr_kprobe
     ->arch_remove_optimized_kprobe
     ->arch_remove_kprobe
     ->kfree: the op is freed

Here, if kprobes_module_callback is called and the delayed
unoptimizing probe is picked BEFORE kprobe_o

[PATCH 3/3] man/Makefile.in: regenerate

Timo Juhani Lindfors — 2013-05-22T06:39:55

---
 man/Makefile.in |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/man/Makefile.in b/man/Makefile.in
index fd91fc2..241fccf 100644
--- a/man/Makefile.in
+++ b/man/Makefile.in
< at >< at > -52,7 +52,7 < at >< at > POST_UNINSTALL = :
 build_triplet = < at >build< at >
 host_triplet = < at >host< at >
 target_triplet = < at >target< at >
-< at >BUILD_TRANSLATOR_TRUE< at >am__append_1 = stap.1 stap-prep.1
+< at >BUILD_TRANSLATOR_TRUE< at >am__append_1 = stap.1 stap-prep.1 stap-report.1
 < at >BUILD_SERVER_TRUE< at >< at >HAVE_NSS_TRUE< at >am__append_2 = stap-server.8
 subdir = man
 DIST_COMMON = $(srcdir)/Makefile.in $(srcdir)/Makefile.am \

[PATCH 1/3] man: add man page for stap-report(1)

Timo Juhani Lindfors — 2013-05-22T06:39:53

---
 man/stap-report.1 |   54 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 54 insertions(+), 0 deletions(-)
 create mode 100644 man/stap-report.1

diff --git a/man/stap-report.1 b/man/stap-report.1
new file mode 100644
index 0000000..41c544e
--- /dev/null
+++ b/man/stap-report.1
< at >< at > -0,0 +1,54 < at >< at >
+.\" -*- nroff -*-
+.TH STAP\-REPORT 1
+.SH NAME
+stap\-report \- collect system information that is useful for debugging systemtap bugs
+
+.\" macros
+.de SAMPLE
+.br
+.RS
+.nf
+.nh
+..
+.de ESAMPLE
+.hy
+.fi
+.RE
+..
+
+.SH SYNOPSIS
+
+.br
+.B stap\-report
+
+.SH DESCRIPTION
+
+The stap\-report executable collects system information that is useful
+for debugging systemtap bugs. It is a good idea to include such a
+report in bug reports especially if you send them directly to the
+upstream. stap\-report can be run either as a normal user or as
+root. The report will be more complete if stap\-report is run as root.
+
+.SH EXAMPLES
+.SAMPLE
+$ stap-report > report.txt
+$ head report.txt
+==

[PATCH 2/3] man/Makefile.am: add stap-report.1

Timo Juhani Lindfors — 2013-05-22T06:39:54

---
 man/Makefile.am |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/man/Makefile.am b/man/Makefile.am
index 4ad0209..724e720 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
< at >< at > -19,7 +19,7 < at >< at > install-data-local:
 done
 
 if BUILD_TRANSLATOR
-man_MANS += stap.1 stap-prep.1
+man_MANS += stap.1 stap-prep.1 stap-report.1
 endif
 
 if HAVE_NSS

[PATCH] fixed typo in doc -- replaced /n by \n

Jonathan Lebon — 2013-05-21T21:10:14

Hello everyone,

My name is Jonathan. I'm a new intern at Red Hat in Toronto.
I study Computer Engineering at York University.

Just pushed a small patch to get used to the system!
Looking forward to work with you all!

Cheers,

Jonathan

[Bug server/15083] stapdyn needs system() support

dsmith at redhat dot com — 2013-05-21T20:01:49

http://sourceware.org/bugzilla/show_bug.cgi?id=15083

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from David Smith <dsmith at redhat dot com> 2013-05-21 20:01:49 UTC ---
Fixed in commit c47ea76.

[Bug dyninst/15513] New: add a "runtime" preprocessor conditional

dsmith at redhat dot com — 2013-05-21T19:22:10

http://sourceware.org/bugzilla/show_bug.cgi?id=15513

             Bug #: 15513
           Summary: add a "runtime" preprocessor conditional
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: dyninst
        AssignedTo: systemtap< at >sourceware.org
        ReportedBy: dsmith< at >redhat.com
    Classification: Unclassified


It would be helpful when writing system scripts to have a preprocessor
conditional that would indicate the runtime in use. This would allow script
writers to do things like:

====
%( runtime == "linux" %?
# do something we can only do in kernel mode
%)

%( runtime == "dyninst" %?
# ...
%)

====

This would be most useful in conditionally including kernel probes, only if
we're using the linux runtime.

This would also be useful in writing test cases.

Re: Re: systemtap 2.2.1 installcheck => kernel BUG at .. kprobes.c:707

Masami Hiramatsu — 2013-05-21T02:45:10

Hi,

I've found the root cause of this bug at last.

In the normal path, an optprobe on an init function is
unregistered when a module goes live.

unregister_kprobe(kp)
 -> __unregister_kprobe_top
   ->__disable_kprobe
     ->disarm_kprobe(ap == op)
       ->__disarm_kprobe
        ->unoptimize_kprobe : the op is queued
                              on unoptimizing_list
and do nothing in __unregister_kprobe_bottom

After a while (usually wait 5 jiffies), kprobe_optimizer runs
to unoptimize and free optprobe.

kprobe_optimizer
 ->do_unoptimize_kprobes
   ->arch_unoptimize_kprobes : moved to free_list
 ->do_free_cleaned_kprobes
   ->hlist_del: the op is removed
   ->free_aggr_kprobe
     ->arch_remove_optimized_kprobe
     ->arch_remove_kprobe
     ->kfree: the op is freed

Here, if kprobes_module_callback is called and the delayed
unoptimizing probe is picked BEFORE kprobe_optimizer runs,

kprobes_module_callback
 ->kill_kprobe
   ->kill_optimized_kprobe : dequeued from unoptimizing_list <=!!!
     ->arch_rem

new systemtap snapshot available

2013-05-18T14:27:04

A new automated systemtap source snapshot is available
ftp://sourceware.org/pub/systemtap/snapshots/systemtap-20130518.tar.bz2
2079411 bytes, 90efadc tag
See also ftp://sourceware.org/pub/systemtap/snapshots/

Re: systemtap 2.2.1 installcheck => kernel BUG at .. kprobes.c:707

Timo Juhani Lindfors — 2013-05-17T18:25:56

No time right now but I pinged the Debian elfutils maintainer to upload
a newer version.

Re: systemtap 2.2.1 installcheck => kernel BUG at .. kprobes.c:707

Timo Juhani Lindfors — 2013-05-17T18:24:48

If I don't pass --rlimit-stack arguments it does not crash.

Re: systemtap 2.2.1 installcheck => kernel BUG at .. kprobes.c:707

Mark Wielaard — 2013-05-17T18:20:25

Since this is elfutils < 0.154 then you might be hitting the bug that
this test was (partially) written for:

commit 581c3f60e2b1fc7ddaf4260bb5a9cb59f8e3f0d0
Author: Tom Tromey <tromey< at >redhat.com>
Date:   Wed Mar 21 08:54:32 2012 -0600

    Fix bug using dwarf_next_unit to iterate over .debug_types

Could you upgrade to 0.154 (or the latest 0.155) version of elfutils and
retest?

Thanks,

Mark

[Bug dyninst/15486] stapdyn get hung when printing debug messages

dsmith at redhat dot com — 2013-05-17T18:18:57

http://sourceware.org/bugzilla/show_bug.cgi?id=15486

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from David Smith <dsmith at redhat dot com> 2013-05-17 18:18:57 UTC ---
Fixed in 90efadc, which also adds a new test for _stp_dbug().

Re: systemtap 2.2.1 installcheck => kernel BUG at .. kprobes.c:707

Mark Wielaard — 2013-05-17T18:18:35

I am not sure what the rlimit references do here. But if it is limiting
the stack a lot, then that might be it. dwarf_getsrclines () uses some
alloca () calls for temporary memory.

[...]

The NEW_LINE define uses alloca.

Try the same stap command without the -rlimit-stack=... arguments to see
if that is it.

Cheers,

Mark