dsmith at redhat dot com | 30 Apr 19:45 2015

[Bug translator/18361] New: systemtap doesn't realize RHEL7 kernels require secure-boot signed modules

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

            Bug ID: 18361
           Summary: systemtap doesn't realize RHEL7 kernels require
                    secure-boot signed modules
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
  Target Milestone: ---

Systemtap doesn't realize RHEL7 kernels require secure-boot signed modules.
This is because RHEL7 has an extra level of security. This feature is shown
here:

<https://patchwork.kernel.org/patch/2862151/>

Systemtap will need to support this BSD-style 'securelevel' feature.

--

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

[Bug translator/18340] New: Segmentation fault of probed SSHD program

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

            Bug ID: 18340
           Summary: Segmentation fault of probed SSHD program
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: fahadaliarshad at gmail dot com
  Target Milestone: ---

Hi,

This bug appears to be similar to this
(https://sourceware.org/bugzilla/show_bug.cgi?id=12458) but I think elfutils is
not the issue.

I compiled the following openssh server versions to be probed by systemtap and
all versions are segfaulting when probed by systemtap versions 2.4/0.156,
2.7/0.156 on my 3.13.6-100.fc19:

To make sure that it is not elfutils, I also reproduced the same problem on
centos7 3.10.0-123.9.3.el7.x86_64 with systemtap version 2.8/0.158, commit
release-2.7-16-gbac8aa5aa94c

When I don't execute the probes the openssh-server executes normally and
clients can connect via sftp.
(Continue reading)

mcermak at redhat dot com | 24 Apr 16:27 2015

[Bug runtime/18320] New: ring_buffer.exp error: implicit declaration of function '__get_cpu_var'

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

            Bug ID: 18320
           Summary: ring_buffer.exp error: implicit declaration of
                    function '__get_cpu_var'
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com

When running ring_buffer.exp I see a regression on f20. The testcase was
passing with kernel-3.18.9-100.fc20, but with 3.19.3-100.fc20 it fails.
Observed on both i686 and x86_64. Compiler version was gcc version 4.8.3
20140911 (Red Hat 4.8.3-7) in both cases. 

Issue also reproducible with  f21's gcc-4.9.2-6.fc21.x86_64 on top of
3.19.4-200.fc21.x86_64.

Issue observed observed comparing stap git commit d71ab77 (where it passed) to
81e4501 (where it failed). But after attempting to bisect sources I believe the
issue is caused by underlying kernel change.

Full logs available at https://url.corp.redhat.com/374766f. The systemtap.log
fragment:

=======
(Continue reading)

Athira | 24 Apr 13:50 2015
Picon

[PATCH] Adding ppc64le loader to interpreter list

listing_mode.exp tests using stap -l for process.library are failing on 
ppc64le.

Using the liblisting_mode.so library and executable from the testsuite, 
stap  -l is not listing any probe points.

#stap -l 'process.library("liblisting_mode.so").function("libfoo")' -c 
listing_mode

Running with verbose mode:
"WARNING: module /usr/share/systemtap/testsuite/listing_mode --ldd 
skipped: unsupported interpreter: /lib64/ld64.so.2"

This is because /lib64/ld64.so.2 is not added in the interpreter list. 
So Adding the ppc64le loader to the code.

Signed-off-by: Athira Rajeev <atrajeev <at> in.ibm.com>
---
  dwflpp.cxx | 1 +
  1 file changed, 1 insertion(+)

diff --git a/dwflpp.cxx b/dwflpp.cxx
index fd104e9..28b9dcb 100644
--- a/dwflpp.cxx
+++ b/dwflpp.cxx
 <at>  <at>  -1287,6 +1287,7  <at>  <at>  dwflpp::iterate_over_libraries<void>(void 
(*callback)(void*, const char*),
        && interpreter != "/lib/ld-linux.so.3"            // arm
        && interpreter != "/lib/ld-linux-armhf.so.3"      // arm
        && interpreter != "/lib/ld-linux-aarch64.so.1"    // arm64
(Continue reading)

dsmith at redhat dot com | 23 Apr 16:15 2015

[Bug tapsets/18309] New: the [nd_]syscall.{sigpending,sigsuspend,sigaltstack} probes need improvement/testing

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

            Bug ID: 18309
           Summary: the [nd_]syscall.{sigpending,sigsuspend,sigaltstack}
                    probes need improvement/testing
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com

The [nd_]syscall.{sigpending,sigsuspend,sigaltstack} probes need improvement
and testing. As an example of the needed improvements, the sigsuspend probes
have an empty 'argstr' variable, while the function gets an argument.

--

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

dsmith at redhat dot com | 20 Apr 23:26 2015

[Bug tapsets/18284] New: some of the rt_* syscalls need improved/added tapset support

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

            Bug ID: 18284
           Summary: some of the rt_* syscalls need improved/added tapset
                    support
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com

Some of the rt_* syscalls need improved/added tapset support:

- [nd_]syscall.rt_sigqueueinfo - needs argstr improvements and better testing
- [nd_]syscall.rt_sigsuspend) - needs argstr improvements and better testing
- [nd_]syscall.rt_sigtimedwait - needs argstr improvements and better testing
- [nd_]syscall.rt_tgsigqueueinfo - needs tapset/testing support

--

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

Hemant Kumar | 20 Apr 12:29 2015
Picon

[PATCH v4 1/3] systemtap/tapsets.cxx: Fix dwarfless probes on multiple static functions

With multiple static functions with same names in an ELF and in absence
of dwarf, if we probe on one of the functions, then systemtap places
probe only on one static function ignoring the rest. This is because the
mapping between the symbol names and their func_info is a simple map
which doesn't allow insertion of another symbol with the same name.

This patch fixes this issue by changing this map to a multimap which
allows duplicate entries for the same symbol name. lookup_symbol code
will return a set of func_info * instead of a single descriptor for a
function name.

We also need to fix other areas in the code where lookup_symbol() and
lookup_symbol_address() are being called so as to look for a set of
func_info's and a list of Dwarf_Addr's respectively, instead of a single
descriptor.

Signed-off-by: Hemant Kumar <hemant <at> linux.vnet.ibm.com>
---
 tapsets.cxx | 90 ++++++++++++++++++++++++++++++++++++++-----------------------
 1 file changed, 56 insertions(+), 34 deletions(-)

diff --git a/tapsets.cxx b/tapsets.cxx
index 443fb2e..c96c542 100644
--- a/tapsets.cxx
+++ b/tapsets.cxx
 <at>  <at>  -395,7 +395,7  <at>  <at>  struct
 symbol_table
 {
   module_info *mod_info;	// associated module
-  map<string, func_info*> map_by_name;
(Continue reading)

Mayuresh Kulkarni | 16 Apr 07:15 2015

userspace probe breakage with gcc 4.8 due to inablility to locate semaphore variable

Hello,

I had a userspace probe (details below) and this worked fine with stap 1.6 and gcc 4.6.  After upgrading to gcc
4.8, this has stopped working. (I believe this to be the only change, everything else on the box is the same)

stap –L detects the probe as follows:

$  stap -L 'process("/tmp/app").provider(“foo”).mark("*")'
process("/tmp/app").provider(“foo”).mark("bar")


But, stap –g –vvvvv with the following probe fails with failure to find foo_bar_semaphore

probe process("/tmp/app").provider("foo").mark("bar")
{…}

dwarf_builder::build for /tmp/app
pattern '/tmp/app' matches module '/tmp/app'
focused on module '/tmp/app' = [0x0x400000, -0x0x6bc09d8, bias 0x0 file /tmp/app ELF machine |x86_64
(code 62)
focused on module '/tmp/app'
TOK_MARK: ipsendv TOK_PROVIDER: foo
pattern 'bar' matches function 'bar'
pattern 'foo' matches function 'foo'
saw .note.stapsdt ipsendv (provider foo)   <at> 0xf515bb
matched probe_name bar probe type uprobe3 at 0xf515bb
probe_type == uprobe3, use statement addr: 0xf515bb
pattern '/tmp/tcp_app' matches module '/tmp/app'
focused on module '/tmp/app' = [0x0x400000, -0x0x6bc09d8, bias 0x0 file /tmp/app ELF machine |x86_64
(code 62)
(Continue reading)

dsmith at redhat dot com | 14 Apr 23:31 2015

[Bug tapsets/18264] New: the 'name_to_handle_at' and 'open_by_handle_at' syscalls need tapset support

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

            Bug ID: 18264
           Summary: the 'name_to_handle_at' and 'open_by_handle_at'
                    syscalls need tapset support
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com

The 'name_to_handle_at' and 'open_by_handle_at' syscalls need tapset support.
There should be syscall and nd_syscall probes for them.

--

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

maxvt at bu dot edu | 14 Apr 17:35 2015

[Bug tapsets/18263] New: In tty tapset, driver_name can be null, causing a script to fail when probing tty.write or tty.read

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

            Bug ID: 18263
           Summary: In tty tapset, driver_name can be null, causing a
                    script to fail when probing tty.write or tty.read
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: maxvt at bu dot edu

Seeing this error from my script:

ERROR: kernel string copy fault at 0x  (null) [man error::fault] near
identifier 'kernel_string' at
/usr/share/systemtap/tapset/linux/conversions.stp:18:10

Narrowed down to a tty.write tap. Investigating the parameters by patching the
tapset like this: 

probe tty.write = kernel.function("n_tty_write") !,
          kernel.function("write_chan")
{
        // [mt]
        printf("buf=%p tty=%p\n", $buf, $tty)
        printf("ttydr=%p ttydrn=%p\n", $tty->driver, $tty->driver->driver_name)

(Continue reading)

dsmith at redhat dot com | 14 Apr 16:53 2015

[Bug tapsets/18262] New: The 'sync_file_range' and 'syncfs' syscalls need tapset support

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

            Bug ID: 18262
           Summary: The 'sync_file_range' and 'syncfs' syscalls need
                    tapset support
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com

The 'sync_file_range' and 'syncfs' syscalls need tapset support. There should
be syscall and nd_syscall probes for them.

--

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


Gmane