dsmith at redhat dot com | 27 May 19:58 2016

[Bug runtime/20161] New: VM_FAULT_MINOR has been removed from rawhide kernels

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

            Bug ID: 20161
           Summary: VM_FAULT_MINOR has been removed from rawhide kernels
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
  Target Milestone: ---

On rawhide kernels (4.7.0-0.rc0.git5.1.fc25.x86_64), VM_FAULT_MINOR is no
longer defined. This causes problems for tapset/linux/memory.stp:

====
# stap -p4 --compatible=2.9
/discer.farm/es/scratch/dsmith/systemtap/src/testsuite/buildok/memory-embedded.stp^M
/tmp/stapMCPqTA/stap_43205e040089fef25e73c052e0db182d_6958_src.c: In function
'function___global_vm_fault_contains__overload_0':
/tmp/stapMCPqTA/stap_43205e040089fef25e73c052e0db182d_6958_src.c:742:34: error:
'VM_FAULT_MINOR' undeclared (first use in this function)
  case 2: res = STAP_ARG_value == VM_FAULT_MINOR; break;
                                  ^~~~~~~~~~~~~~
/tmp/stapMCPqTA/stap_43205e040089fef25e73c052e0db182d_6958_src.c:742:34: note:
each undeclared identifier is reported only once for each function it appears
in
scripts/Makefile.build:291: recipe for target
(Continue reading)

fche at redhat dot com | 27 May 18:34 2016

[Bug runtime/11428] tcp_wrappers for limiting stap-server access

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

Frank Ch. Eigler <fche at redhat dot com> changed:

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

--- Comment #1 from Frank Ch. Eigler <fche at redhat dot com> ---
no recent need

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
dsmith at redhat dot com | 27 May 16:56 2016

[Bug runtime/20158] New: on kernel 4.6, print_backtrace() gets a compile error

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

            Bug ID: 20158
           Summary: on kernel 4.6, print_backtrace() gets a compile error
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
  Target Milestone: ---

As reported on the mailing list
(<https://sourceware.org/ml/systemtap/2016-q2/msg00161.html>),
print_backtrace() gets a compile error on the 4.6 kernel.

====
# cat read_test.stp
probe kernel.function("vfs_read"){
    print("----------------START-------------------------\n")
    printf("In process [%s]\n", execname())
    printf("on CPU [%d]\n", cpu())
    print_backtrace()
    print("----------------END-------------------------\n")
    exit()
}
# stap -vp4 read_test.stp 
Pass 1: parsed user script and 113 library scripts using
(Continue reading)

chenyu | 27 May 15:47 2016
Picon

print_backtrace compile error

Hi all,
Currently I'm trying to use systemtap
from git://sourceware.org/git/systemtap.git
on top of linux 4.6.

It looks like I can not get print_backtrace work,
maybe due to missing some structure definition
in stacktrace.h, other function such as execname()
and cpu() work as expected:

$ cat read_test.stp
$ ! /usr/bin/env stap

probe kernel.function("vfs_read"){
        print("----------------START-------------------------\n")
        printf("In process [%s]\n", execname())
        printf("on CPU [%d]\n", cpu())
        print_backtrace()
        print("----------------END-------------------------\n")
        exit()
}

#  ./read_test.stp
In file included from
/tmp/stapPYCfpw/stap_8230e12f26deacb5ff73e22d31f00161_3127_src.c:227:0:
/usr/local/share/systemtap/runtime/stack.c:133:2: error:
initialization from incompatible pointer type [-Werror]
  .address = print_stack_address,
  ^
/usr/local/share/systemtap/runtime/stack.c:133:2: error: (near
(Continue reading)

jistone at redhat dot com | 26 May 20:13 2016

[Bug translator/20149] New: a function probe with a line number acts like a statement probe

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

            Bug ID: 20149
           Summary: a function probe with a line number acts like a
                    statement probe
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: jistone at redhat dot com
  Target Milestone: ---

If you probe a function with a line number different than its entry, you'll get
a warning that a statement probe was probably what you wanted.  Then it
*should* act like a function-entry probe anyway, but instead it proceeds like a
statement.

First a plain function probe:

$ stap -p2 -e 'probe process("stap").function("main <at> main.cxx") {next}'
# probes
process("/usr/local/bin/stap").function("main <at> ../main.cxx:1123") /*
pc=.absolute+0xfc80 */ /* <-
process("/usr/local/bin/stap").function("main <at> ../main.cxx:1123") */

Now change the line number:

(Continue reading)

fche at redhat dot com | 26 May 19:30 2016

[Bug releng/5733] selinux policy

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

Frank Ch. Eigler <fche at redhat dot com> changed:

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

--- Comment #1 from Frank Ch. Eigler <fche at redhat dot com> ---
no recent need; only stap-server a realistic candidate anyway

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
dsmith at redhat dot com | 26 May 16:13 2016

[Bug runtime/20148] New: kernel BUGs while doing parallel testing

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

            Bug ID: 20148
           Summary: kernel BUGs while doing parallel testing
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
  Target Milestone: ---

While doing a parallel testsuite run on the debug RHEL7 ppc64 kernel
(3.10.0-327.el7.ppc64.debug), I see the following kernel BUGs (a mix of
"sleeping function called from invalid context" and "scheduling while atomic"):

====
May 25 16:03:44 ibm-p740-01-lp5.rhts.eng.bos.redhat.com kernel: BUG: sleeping
function called from invalid context at kernel/mutex.c:576
May 25 16:03:44 ibm-p740-01-lp5.rhts.eng.bos.redhat.com kernel: in_atomic(): 1,
irqs_disabled(): 0, pid: 27280, name: stapio
May 25 16:03:44 ibm-p740-01-lp5.rhts.eng.bos.redhat.com kernel: INFO: lockdep
is turned off.
May 25 16:03:44 ibm-p740-01-lp5.rhts.eng.bos.redhat.com kernel: CPU: 10 PID:
27280 Comm: stapio Tainted: G           OE  ------------  
3.10.0-327.el7.ppc64.debug #1
May 25 16:03:44 ibm-p740-01-lp5.rhts.eng.bos.redhat.com kernel: Call Trace:
May 25 16:03:44 ibm-p740-01-lp5.rhts.eng.bos.redhat.com kernel:
(Continue reading)

Evan Klitzke | 26 May 10:44 2016
Gravatar

How do uprobes work?

Hi,

I'm interested in learning more about how uprobes work with systemtap.
I read the wiki page about userspace probes which covers how to add
markers to a userspace application, and which mentions that the probes
expand to a single nop instruction. How does systemtap then actually
probe the process? If I had to guess I'd speculate that similar to a
GDB breakpoint, the nop for a probed process is replaced with a trap
instruction, and then the kernel knows that a trap generated at that
address is intended for systemtap; but I don't really know, and I'm
interested to learn more.

Another related question: when I run a systemtap script to trace a
userspace process, what functionality exactly is running in the kernel
and what is running in userspace? I found the uprobetracer.txt
document in the kernel and it looks like the uprobe events can be
controlled and written via sysfs files. Is it accurate that systemtap
scripts work by implementing most of the logic (e.g. maintaining hash
tables, counters, and so forth) in a userspace process which gets it
data from reading sysfs files?

Cheers,
Evan

fche at redhat dot com | 24 May 21:31 2016

[Bug documentation/6751] Web site mega-review

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

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
                 CC|                            |fche at redhat dot com
           Assignee|wcohen at redhat dot com           |systemtap at sourceware dot org

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
fche at redhat dot com | 24 May 20:21 2016

[Bug kprobes/2064] Support pagepoint probes

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

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |fche at redhat dot com
         Resolution|---                         |WONTFIX

--- Comment #6 from Frank Ch. Eigler <fche at redhat dot com> ---
no recent need

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
mcermak at redhat dot com | 24 May 11:43 2016

[Bug tapsets/20136] New: Use the <at> const() operator across the tapset scripts.

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

            Bug ID: 20136
           Summary: Use the  <at> const() operator across the tapset scripts.
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com
  Target Milestone: ---

PR19926 adds a new  <at> const() operator to the translator.  Attached patch is a
kick-off attempt to use  <at> const() across the tapset scripts where possible. 
It's rather large.  It went through one round of testing and fixing on my side
and now seems to test fine.  In some cases it changes/extends the original
annotations, but hopefully in a reasonable way.

There might be more opportunities to use  <at> const() in the tapset scripts. 
Notably I've been looking at bodies of stp_pid(), tz_gmtoff(), and tz_name()
(which is a /* string */).  I've been rather conservative.

However, I see one problem: The attached patch doesn't have one particular
update that I'd like to do, but can't:  In tapset/macros.stpm, there is a
MAXSTRINGLEN macro. It looks like a promising candidate for an update similar
to this:

=======
(Continue reading)


Gmane