http://blog.gmane.org/gmane.linux.systemtap hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.systemtap/19373 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14168 Bug #: 14168 Summary: sanitize environment better for invoking kernel-module-builder make Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: translator AssignedTo: systemtap&lt; at &gt;sourceware.org ReportedBy: fche&lt; at &gt;redhat.com Classification: Unclassified Sometimes stap is invoked with a $PATH etc. that is not suitable for building kernel modules, for example if an oddball compiler happens to be first. Encourage buildrun.cxx to use the "system" compiler, assumed in /usr/bin. Unfortunately, the kernel kbuild mechanism doesn't offer hints as to where the compiler may have been when the original kernel was built. </pre> fche at redhat dot com 2012-05-25T14:49:34 http://permalink.gmane.org/gmane.linux.systemtap/19372 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14165 Serguei Makarov &lt;smakarov at redhat dot com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|systemtap at sourceware dot |smakarov at redhat dot com |org | </pre> smakarov at redhat dot com 2012-05-24T19:19:29 http://permalink.gmane.org/gmane.linux.systemtap/19371 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14165 Bug #: 14165 Summary: netfilter.stp -- extract IPV6 protocol info Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: tapsets AssignedTo: systemtap&lt; at &gt;sourceware.org ReportedBy: smakarov&lt; at &gt;redhat.com Classification: Unclassified netfilter.stp needs to fully expose netfilter's IPv6 support. Currently we do not extract the protocol header, nor any of the information which requires extracting it. We need to wrap ipv6_skip_exthdr() for the extraction. </pre> smakarov at redhat dot com 2012-05-24T19:17:24 http://permalink.gmane.org/gmane.linux.systemtap/19370 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14164 Serguei Makarov &lt;smakarov at redhat dot com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|systemtap at sourceware dot |smakarov at redhat dot com |org | </pre> smakarov at redhat dot com 2012-05-24T19:10:45 http://permalink.gmane.org/gmane.linux.systemtap/19369 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14164 Bug #: 14164 Summary: netfilter.stp -- expose arp and bridge protocol info Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: tapsets AssignedTo: systemtap&lt; at &gt;sourceware.org ReportedBy: smakarov&lt; at &gt;redhat.com Classification: Unclassified Add support to the netfilter.stp tapset to use netfilter support for probing ARP and "bridge" protocols (e.g. probe netfilter.arp.in). Need to find out exactly which protocols correspond to "bridge". (follows on from PR13667) </pre> smakarov at redhat dot com 2012-05-24T19:04:58 http://permalink.gmane.org/gmane.linux.systemtap/19368 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14146 Serguei Makarov &lt;smakarov at redhat dot com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|systemtap at sourceware dot |smakarov at redhat dot com |org | --- Comment #1 from Serguei Makarov &lt;smakarov at redhat dot com&gt; 2012-05-24 18:58:01 UTC --- doc/Tapset_Reference_Guide/manpager.sh does *roughly* what we need it to do (namely, munge the tapset source code to produce man pages). It can be adapted the rest of the way, either fixing the existing script or rewriting it in something sane like Perl. Anyhow, assigning the issue to myself now that it's clear what to do. </pre> smakarov at redhat dot com 2012-05-24T18:58:01 http://permalink.gmane.org/gmane.linux.systemtap/19367 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14146 Bug #: 14146 Summary: tapset::* man pages should be generated from actual tapset files Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: documentation AssignedTo: systemtap&lt; at &gt;sourceware.org ReportedBy: smakarov&lt; at &gt;redhat.com Classification: Unclassified Currently, the man/tapset::*.3stap manual pages are hand-written. This is unnecessary and error-prone duplication, as they could just as easily be auto-generated from the comments in the corresponding .stp file (as is already done for the tapset reference manual). </pre> smakarov at redhat dot com 2012-05-23T15:18:28 http://permalink.gmane.org/gmane.linux.systemtap/19366 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14137 Serguei Makarov &lt;smakarov at redhat dot com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|systemtap at sourceware dot |cmeek at redhat dot com |org | --- Comment #1 from Serguei Makarov &lt;smakarov at redhat dot com&gt; 2012-05-23 13:41:29 UTC --- Yes, this is a known bug, which is why there's a test for it. There's some kind of extremely subtle issue with how derived probes are named. </pre> smakarov at redhat dot com 2012-05-23T13:41:29 http://permalink.gmane.org/gmane.linux.systemtap/19365 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14137 Bug #: 14137 Summary: buildok/netfilter02.stp not ok Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: translator AssignedTo: systemtap&lt; at &gt;sourceware.org ReportedBy: mjw&lt; at &gt;redhat.com CC: cmeek&lt; at &gt;redhat.com, smakarov&lt; at &gt;redhat.com Classification: Unclassified Host: Linux toonder.wildebeest.org 3.3.6-3.fc16.x86_64 #1 SMP Wed May 16 21:43:01 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Snapshot: version 1.8/0.153 commit release-1.7-249-g57db0e6 GCC: 4.6.3 [gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)] Distro: Fedora release 16 (Verne) Running /home/mark/src/systemtap/testsuite/buildok/netfilter02.stp starting /home/mark/src/systemtap/testsuite/buildok/netfilter02.stp spawn1 stap -p4 /home/mark/src/systemtap/testsuite/buildok/netfilter02.stp spawn stap -p4 /home/mark/src/systemtap/testsuite/buildok/netfilter02.stp WARNING: side-effect-free probe 'probe_2009': keyword at /home/mark/src/systemtap/testsuite/buildok/netfilter02.stp:4:1 source: probe netfilter.hook("NF_INET_PRE_ROUTING").pf("NFPROTO_IPV4").priority("1") { } ^ WARNING: side-effect-free probe 'probe_2010': keyword at :5:1 WARNING: side-effect-free probe 'probe_2009': keyword at /home/mark/src/systemtap/testsuite/buildok/netfilter02.stp:4:1 source: probe netfilter.hook("NF_INET_PRE_ROUTING").pf("NFPROTO_IPV4").priority("1") { } ^ WARNING: side-effect-free probe 'probe_2010': keyword at :5:1 source: probe netfilter.hook("NF_INET_PRE_ROUTING").pf("NFPROTO_IPV4") { } ^ source: probe netfilter.hook("NF_INET_PRE_ROUTING").pf("NFPROTO_IPV4") { } ^ /tmp/stapTNRaVj/stap_ed0c182d855bb272214e55124b74424b_883_src.c:231:21: error: redefinition of 'enter_netfilter_probe_probe_2009' /tmp/stapTNRaVj/stap_ed0c182d855bb272214e55124b74424b_883_src.c:106:21: note: previous definition of 'enter_netfilter_probe_probe_2009' was here /tmp/stapTNRaVj/stap_ed0c182d855bb272214e55124b74424b_883_src.c:231:21: error: redefinition of 'enter_netfilter_probe_probe_2009' /tmp/stapTNRaVj/stap_ed0c182d855bb272214e55124b74424b_883_src.c:106:21: note: previous definition of 'enter_netfilter_probe_probe_2009' was here /tmp/stapTNRaVj/stap_ed0c182d855bb272214e55124b74424b_883_src.c:349:27: error: redefinition of 'netfilter_opts_probe_2009' /tmp/stapTNRaVj/stap_ed0c182d855bb272214e55124b74424b_883_src.c:224:27: note: previous definition of 'netfilter_opts_probe_2009' was here /tmp/stapTNRaVj/stap_ed0c182d855bb272214e55124b74424b_883_src.c:349:27: error: redefinition of 'netfilter_opts_probe_2009' /tmp/stapTNRaVj/stap_ed0c182d855bb272214e55124b74424b_883_src.c:224:27: note: previous definition of 'netfilter_opts_probe_2009' was here make[4]: *** [/tmp/stapTNRaVj/stap_ed0c182d855bb272214e55124b74424b_883_src.o] Error 1 make[4]: *** [/tmp/stapTNRaVj/stap_ed0c182d855bb272214e55124b74424b_883_src.o] Error 1 make[3]: *** [_module_/tmp/stapTNRaVj] Error 2 make[3]: *** [_module_/tmp/stapTNRaVj] Error 2 WARNING: make exited with status: 2 Pass 4: compilation failed. Try again with another '--vp 0001' option. WARNING: make exited with status: 2 Pass 4: compilation failed. Try again with another '--vp 0001' option. wait results: 30850 exp24 0 1 FAIL: buildok/netfilter02.stp </pre> mjw at redhat dot com 2012-05-23T11:30:27 http://permalink.gmane.org/gmane.linux.systemtap/19364 <pre> Does it make sense then ? In case of low throughput use cases, we have been for a long time dumping buffers only every few s isntead of 200us at the cost of printing latency. Rare cases but needed. Regards Fred Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 </pre> Turgis, Frederic 2012-05-22T17:53:37 http://permalink.gmane.org/gmane.linux.systemtap/19363 <pre>Here's what I'm getting with the latest run of the inode-uprobes code: === systemtap Summary === # of expected passes3087 # of unexpected failures136 # of unexpected successes7 # of expected failures246 # of unknown successes1 # of known failures42 # of untested testcases83 # of unsupported tests2 Not too shabby. A good number of the failures, 73, comes from the fact that the inode-uprobes code doesn't have return probes yet and that the systemtap code doesn't support .absolute probes with inode-uprobes since there is no (semi-easy) way to turn a raw address into file inode+offset. Note that it is possible that the failures related to process.return and process.absolute probes are masking other problems. - Tests failing because of the lack of process.return probes (and the number of failures in parens): systemtap.base/at_var.exp (1) systemtap.base/bz10078.exp (2) systemtap.base/bz6850.exp (2) systemtap.base/global_var.exp (6) systemtap.base/library.exp (8) systemtap.base/process_by_cmd.exp (1) systemtap.base/uprobes.exp (4) systemtap.context/fib.exp (2) systemtap.context/uprobe_uaddr.exp (6) systemtap.unprivileged/unprivileged_myproc.exp (18) systemtap.unprivileged/unprivileged_probes.exp (18) - Tests failing because of the lack of process.absolute probes (and the number of failures in parens): systemtap.pass1-4/buildok.exp (1) systemtap.unprivileged/unprivileged_myproc.exp (2) systemtap.unprivileged/unprivileged_probes.exp (2) - Here's a list of failing testcases that looks like legitimate bugs in the new code: systemtap.base/itrace.exp systemtap.base/plt.exp systemtap.clone/dtrace_vfork_exec.exp systemtap.context/uprobe_stmt_num.exp systemtap.exelib/pthreadprobes.exp I've attached the systemtap.sum. </pre> David Smith 2012-05-21T18:58:56 http://permalink.gmane.org/gmane.linux.systemtap/19362 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14107 Mark Wielaard &lt;mjw at redhat dot com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Mark Wielaard &lt;mjw at redhat dot com&gt; 2012-05-21 11:01:19 UTC --- Not really "fixed", but with the proper kernel patch, see comment #5, this should just work. Added a testcase to check the system is behaving properly. commit 07c9d78ebb28b888f01aed9c206e724f0e72db25 Author: Mark Wielaard &lt;mjw&lt; at &gt;redhat.com&gt; Date: Mon May 21 12:57:41 2012 +0200 Add testcase for PR14107 Bad user unwinding from kernel fatal signal handler This is really a kernel bug, see bug report, when the CFI for the assembly code is missing we cannot properly recover the register state for the user process and might give a bad/missing user backtrace. </pre> mjw at redhat dot com 2012-05-21T11:01:19 http://permalink.gmane.org/gmane.linux.systemtap/19361 <pre>A new automated systemtap source snapshot is available ftp://sourceware.org/pub/systemtap/snapshots/systemtap-20120519.tar.bz2 1966866 bytes, 4e8c027 tag See also ftp://sourceware.org/pub/systemtap/snapshots/ </pre> fche< at >sourceware.org 2012-05-19T14:27:23 http://permalink.gmane.org/gmane.linux.systemtap/19360 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=10607 Frank Ch. Eigler &lt;fche at redhat dot com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|need way to disable |need way to protect |global-setting module |sensitive tapset globals |params | --- Comment #1 from Frank Ch. Eigler &lt;fche at redhat dot com&gt; 2012-05-16 15:53:27 UTC --- Note that it's not sufficient to just disable -G foo=bar. An end-user script could equivalently include probe begin(1) { tapset_global = naughty_value } to mess with this. So we'd need a more general mechanism to protect tapset internal globals, whose change could cause problems. </pre> fche at redhat dot com 2012-05-16T15:53:27 http://permalink.gmane.org/gmane.linux.systemtap/19359 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=13745 --- Comment #6 from David Smith &lt;dsmith at redhat dot com&gt; 2012-05-15 19:41:20 UTC --- (In reply to comment #5) Originally it worked for me with 2.6.32-220.7.1.el6.x86_64. I just upgraded to 2.6.32-220.13.1.el6.x86_64 and it still works fine. </pre> dsmith at redhat dot com 2012-05-15T19:41:20 http://permalink.gmane.org/gmane.linux.systemtap/19358 <pre> I'm missing something. Why does the second item not moot the first? IOW, if we poll with a 5s timeout, why wouldn't the timer.s(1) reports wake up the ppoll() to avoid waiting till 5s? [FT] ppoll() wakes-up only when 1 buffer is full. timer.s(1) wakes-up whatever kernel thread (by the way, I should check that with contextswitch trace) but trace throughput is very low. After 5 seconds, ppoll time-outs and the 5 traces done by timer.s(1) at every second are dumped. When I say "do not use", it is really for interactivity with terminal. People may want to get some small metric every s, but 5 metrics will be displayed every 5s. Of course, for a log read later, you don't care. So, yes, people should be cautious with this but well, this is for embedded platforms and this is really our goal. - FChE Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 </pre> Turgis, Frederic 2012-05-15T15:29:38 http://permalink.gmane.org/gmane.linux.systemtap/19357 <pre> Hi, Frederic - f-turgis wrote: I'm missing something. Why does the second item not moot the first? IOW, if we poll with a 5s timeout, why wouldn't the timer.s(1) reports wake up the ppoll() to avoid waiting till 5s? - FChE </pre> Frank Ch. Eigler 2012-05-15T14:24:48 http://permalink.gmane.org/gmane.linux.systemtap/19356 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14107 --- Comment #5 from Mark Wielaard &lt;mjw at redhat dot com&gt; 2012-05-15 14:14:41 UTC --- Looks like the RHEL6 kernel is missing this: commit 9e565292270a2d55524be38835104c564ac8f795 Author: Roland McGrath &lt;roland&lt; at &gt;redhat.com&gt; Date: Thu May 13 21:43:03 2010 -0700 x86: Use .cfi_sections for assembly code The newer assemblers support the .cfi_sections directive so we can put the CFI from .S files into the .debug_frame section that is preserved in unstripped vmlinux and in separate debuginfo, rather than the .eh_frame section that is now discarded by vmlinux.lds.S. Signed-off-by: Roland McGrath &lt;roland&lt; at &gt;redhat.com&gt; LKML-Reference: &lt;20100514044303.A6FE7400BE&lt; at &gt;magilla.sf.frob.com&gt; Signed-off-by: H. Peter Anvin &lt;hpa&lt; at &gt;zytor.com&gt; </pre> mjw at redhat dot com 2012-05-15T14:14:41 http://permalink.gmane.org/gmane.linux.systemtap/19355 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14107 --- Comment #4 from Mark Wielaard &lt;mjw at redhat dot com&gt; 2012-05-15 14:07:27 UTC --- The problem isn't the CFI for do_page_fault, but that there is no CFI for page_fault. Nor does there seem to be any CFI for any assembly symbol defined in entry_64.S. Which explains why unwinding to the kernel/user space barrier just fails. No idea yet, why the CFI isn't included in /usr/lib/debug/lib/modules/*/vmlinux for the RHEL6 kernel, it certainly is there in entry_64.S source code. And it also is in the fedora version $ eu-readelf --debug-dump=frames /usr/lib/debug/lib/modules/3.3.5-2.fc16.x86_64/vmlinux | grep -B2 -A1 page_fault [ 7ae0] FDE length=68 cie=[ 6da8] CIE_pointer: 28072 initial_location: 0xffffffff815f4850 &lt;page_fault&gt; address_range: 0x2a </pre> mjw at redhat dot com 2012-05-15T14:07:27 http://permalink.gmane.org/gmane.linux.systemtap/19354 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14110 --- Comment #2 from william.jon.mccann at gmail dot com 2012-05-15 13:24:27 UTC --- Yeah. Those are the system data dirs. Now we need support for the per-user directories. </pre> william.jon.mccann at gmail dot com 2012-05-15T13:24:27 http://permalink.gmane.org/gmane.linux.systemtap/19353 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=13745 Frank Ch. Eigler &lt;fche at redhat dot com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fche at redhat dot com --- Comment #5 from Frank Ch. Eigler &lt;fche at redhat dot com&gt; 2012-05-15 12:44:23 UTC --- The new mmwriteback.stp gives an semantic_error for kernel.trace("mm_pdflush_kupdate") on 2.6.32-246.el6. What kernel version did that work for you with? </pre> fche at redhat dot com 2012-05-15T12:44:23 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.systemtap