gmane.linux.systemtap

Re: Compilation error when doing user space probe on FC9.

Ananth N Mavinakayanahalli — 2008-12-04T03:41:23

You really need a newer kernel! F9 currently is updated to 2.6.27.5 IIRC. Ananth

Re: registration error (rc -22) on a standard function. Why ?

Ananth N Mavinakayanahalli — 2008-12-04T03:40:07

Possibly part of the SystemTap blacklist. For safety reasons we don't allow probing certain routines (spinlock*, mutex*, atomic*) and this looks to be one of them. Try stap -vv and you'll see a more descriptive error. Ananth

Compilation error when doing user space probe on FC9.

Wenji Huang — 2008-12-04T03:27:03

Hi, Got compilation error when doing userspace probe on FC9. But "probe process.syscall" works fine. $ uname -r 2.6.25-14.fc9.x86_64 $ stap -vve 'probe process("/home/wjhuang/test").function("*") {}' SystemTap translator/driver (version 0.8/0.133 git branch master, commit c1f7a846) Copyright (C) 2005-2008 Red Hat, Inc. and others This is free software; see the source for copying conditions. Session arch: x86_64 release: 2.6.25-14.fc9.x86_64 Created temporary directory "/tmp/stapWDKS9H" Searched '/usr/local/share/systemtap/tapset/x86_64/*.stp', found 2 Searched '/usr/local/share/systemtap/tapset/*.stp', found 45 Pass 1: parsed user script and 47 library script(s) in 400usr/30sys/1078real ms. probe main< at >/home/wjhuang/test.c:10 process=/home/wjhuang/test reloc=.absolute section=.text pc=0x4004df probe func1< at >/home/wjhuang/test.c:5 process=/home/wjhuang/test reloc=.absolute section=.text pc=0x4004d0 WARNING: side-effect-free probe 'probe_1386': keyword at :1:1 source: probe process("/home/wjhuang/

pr6925

Roland McGrath — 2008-12-04T02:41:30

I've pushed two new git branches. pr7063 branch uses SYSTEMTAP_STAPRUN and SYSTEMTAP_STAPIO environment variables Neither these nor the other environment variables affecting stap are documented in the man pages, as far as I noticed. Someone should do that. pr6925 branch forks from pr7063, it adds a run-stap script in the build directory. configure; make; .../run-stap -e 'xxx' works out of the box. The script uses sudo. I hope you all will take it away from here, merge the branches or fix it up or do it differently. And take the new snarky complaint out of configure. Thanks, Roland

registration error (rc -22) on a standard function. Why ?

Breno Leitao — 2008-12-04T00:55:30

Hi, I am trying to probe a function which was static and inline. To probe it, I remove the static and inline modifier, to turn into a standard function, but now I am getting the following error: WARNING: probe module("bonding").function("_lock_tx_hashtbl< at >drivers/net/bonding/bond_alb.c:132") registration error (rc -22) Here is the function: void _lock_tx_hashtbl(struct bonding *bond) { spin_lock_bh(&(BOND_ALB_INFO(bond).tx_hashtbl_lock)); } stap -p2 shows: module("bonding").function("_lock_tx_hashtbl< at >drivers/net/bonding/bond_alb.c:132") /* pc=.text+0x9b00 */ /* <- module("bonding").function("_lock_tx_hashtbl") */ Objdump shows: 0000000000009b00 <._lock_tx_hashtbl>: 9b00: 7c 08 02 a6 mflr r0 9b04: 38 63 01 f0 addi r3,r3,496 9b08: f8 01 00 10 std r0,16(r1) 9b0c: f8 21 ff 91 stdu r1,-112(r1) 9b10: 48 00 00 01 bl 9b10 <._lock_tx_hashtbl+0x10> 9b10: R_PPC64_REL24 ._spin_lock_bh

Re: Network Security for the Systemtap Client/Server

Roland McGrath — 2008-12-03T02:23:25

However, carrying a similar signature in a similar fashion could work just fine. That is, at build time, add a new ELF section to the .ko file containing the signature bits. Then, check this signature against the .ko file's contents before loading the module. Our check can be in staprun, rather than inside the kernel itself as the old modsign scheme does it. Both the signing phase and the checking phase are pretty easy to implement, either crudely with scripts around objcopy or fairly cleanly via libelf and the NSS libraries. Thanks, Roland

Re: Network Security for the Systemtap Client/Server

Roland McGrath — 2008-12-03T02:17:12

One can imagine a compiling server having available local private kernel builds whose internal layout details someone's policy might consider security-sensitive. Leave the policy on authentication requirements to the local admins to choose. Just make out-of-the-box defaults be easy to use without infrastructure set-up even when that means less stringent security policies than a concerned admin could configure. Also, keep in mind the long-run need to mesh with sophisticated key management infrastructure a particular installation might have and want to use it (be required by local security regulations) for everything crypto. I'm not suggesting you dwell on this especially while just getting something going for casual set-up and use. Probably any implementation that can be scripted around somehow using NSS command line tools will fully meet that requirement down the line without much trying. But keep it in my in the approaches taken and how accessible the system is to configuration of how keys are acquire

[Bug translator/6925] make roland happy

roland at gnu dot org — 2008-12-03T22:55:52

[Bug translator/7063] New: do not hard-wire locations of staprun, stapio

roland at gnu dot org — 2008-12-03T22:55:52

There should be some way, via command line switches or environment variables, to choose the locations of the staprun and stapio binaries that are run by stap and staprun respectively.

[Bug translator/6925] make roland happy

roland at gnu dot org — 2008-12-03T22:51:10

[Bug translator/7062] New: uprobes loading does not respect SYSTEMTAP_RUNTIME environment variable

roland at gnu dot org — 2008-12-03T22:51:10

buildrun.cxx should use s.runtime_path + "/uprobes" rather than a hard-coded path.

[Bug translator/6925] make roland happy

fche at redhat dot com — 2008-12-03T22:30:28

------- Additional Comments From fche at redhat dot com 2008-12-03 22:30 ------- This is not a great idea. git commit af29024 offers this advice: configure: configure: For a private or temporary build of systemtap, we recommend configure: configuring with a prefix. For example, try configure: ../systemtap3/configure --prefix=/home/fche/systemtap-0.8-12350 configure: Running systemtap uninstalled, entirely out of the build tree, configure: is not supported. Fixed (better -r option). Fixed (--vp option). Unnecessary if people are willing to follow --prefix advice. commit c94a9cb3 attempts to unload modules left over by a stap* crash or SIGKILL, so that a subsequent stap run will work.

[Bug translator/6925] make roland happy

fche at redhat dot com — 2008-12-03T18:39:04

[Bug translator/7045] user-space probe x86 on x86-64 host

wenji dot huang at oracle dot com — 2008-12-03T08:47:27

------- Additional Comments From wenji dot huang at oracle dot com 2008-12-03 08:47 ------- sorry, don't catch it well. I tried simple test on FC9-64 bits. gcc -m32 -o /tmp/test /tmp/test.c /tmp/test& stap -vvve 'probe process("/tmp/test").syscall{}' Everything is OK. And validate_module_elf wasn't be called neither. Could you elaborate it a little or provide some test cases?

Test results on 2.6.28-rc6

Wenji Huang — 2008-12-03T02:49:54

Hi, These are tests results on 2.6.28-rc6. No much regression. 1. Some failures caused by test cache, like marker.exp 2. Kernel config, like utrace. 3. Machine related, like smp, scsi. Regards, Wenji ------------------------------------------------------------------------------ Package: systemtap_snapshot (0.8/0.131-master(224e23be)-2.6.28_rc6-snapshot) Previous build: 2008/11/17 04:53:56 - 2008/11/17 04:53:56 Current build: 2008/11/26 22:21:14 - 2008/11/26 22:21:14 Host: rctest-32 Platform: Linux 2.6.28-rc6 i386 (EL4U6) (before: Linux 2.6.28-rc5 i386 (EL4U6)) URL: http://build.alchar.org/cgi/showBuild?host=rctest-32&pkg=systemtap_snapshot&date=20081126-222114 First failure: test Test result: 826: 758 +, 40 -, 28 S, 0 E (before: 823: 760 +, 34 -, 29 S, 0 E) Old -> New Test ----- ----- ---------------------------------- FAIL -> PASS test - systemtap.pass1-4/buildok.exp(buildok/sched_test.stp) N/A -> FAIL test - systemtap.base/marker.exp(K_MARKER18

[Bug translator/7053] automatic global printing of statistic needs to check < at >count>0

fche at redhat dot com — 2008-12-02T19:17:53

------- Additional Comments From fche at redhat dot com 2008-12-02 19:17 ------- Nice work, plase commit with a test case.

[Bug runtime/7051] remove broken printf %n directive support

fche at redhat dot com — 2008-12-02T18:03:45

------- Additional Comments From fche at redhat dot com 2008-12-02 18:03 ------- If there is no dissent, let's get rid of it.

Re: Request to add git url in building systemtap guide

Frank Ch. Eigler — 2008-12-02T14:37:27

The wiki is a community resource. You can create yourself a login account and edit the page to your liking. - FChE

Re: Request to add git url in building systemtap guide

Ananth N Mavinakayanahalli — 2008-12-02T14:15:57

Added now. BTW, feel free to create an account for yourself on the wiki and add such details. We'd like for more volunteers to help update and improve documentation on the wiki. Ananth

Re: error inserting module while running sleeptime.stp on maemo platform

Dmitry Malichenko — 2008-12-02T12:30:30

Hi, On Fri, Nov 28, 2008 at 10:03 AM, Ananth N Mavinakayanahalli in.ibm.com> wrote: I enabled CONFIG_RELAY, CONFIG_DEBUG_FS, CONFIG_DEBUG_INFO, CONFIG_KPROBES options. I used systemtap wiki page http://sourceware.org/systemtap/wiki/SystemtapMaemoBenchmark there is a patch there which adds kprobes to the kernel. I also successfully ran some tests from systemtap testsuite. Thanks, Dmitry Malichenko

Request to add git url in building systemtap guide

gowrishankar — 2008-12-02T12:00:44

Hi, Can you please add git url for systemtap source, in "Building Systemtap Mainline" section of link "http://sources.redhat.com/systemtap/wiki/SystemtapOnUbuntu". Currently shown steps are : sudo apt-get install git-core dejagnu sudo apt-get build-dep systemtap cd path/to/systemtap ./configure --disable-pie make && sudo make install Thanks in advance. Gowri