Re: function parameter access in kretprobe handler

bibo.mao <at> intel.com wrote:

> I remembered that previously I saw some scripts where function
> parameter is accessed in return probe function. But I think that
> currently systemtap has not this capability. [...]

Correct.  Please see bug #1382.

- FChE

Re: SystemTAP translator test coverage

Frank Ch. Eigler wrote:
> wcohen wrote:
> 
> 
>>[...]
>>http://people.redhat.com/wcohen/stap_coverage/src/index.html
> 
> 
> Thanks for posting the pretty pictures!
> 
> 
>>There are sections of buildrun.cxx that are not run because the
>>output of the translator was not actually compiled as a module or
>>installed in the kernel. The translator tests do not exercise the
>>tapsets.cxx code either.
> 
> 
> That's odd - the transok/buildok tests should exercise the tapsets.cxx
> code.

Ah, this was on my laptop which doesn't have a matching debuginfo for 
the kernel that is running on it. The results looked a bit better on my 
p6 machine that had a debuginfo matching the kernel.

I have placed the revised results from today's checkout "make gcov" on a 
FC4 pentium M machine at:

http://people.redhat.com/wcohen/stap_coverage/

>>Looking at parse.cxx and translate.cxx there are a number of cases

Translator coverage of pass 5 testsuite

Today I was able to set things up to collect coverage data on the stap 
translator when running the pass-5 testsuite. I have posted the lcov 
results at:

http://people.redhat.com/wcohen/coverage_runtest20060104/

This was on a FC4 pentium M machine:

                 === systemtap Summary ===

# of expected passes            110
# of unexpected failures        1

kernel version: 2.6.14-1.1653_FC4
systemtap translator version: version 0.5.2 built 2006-01-03

Something is wrong with the systemtap.stress/current.exp on FC4. Which 
versions of the kernel did current.stp work with? It died with the FC4 
kernel:

Running ./systemtap.stress/current.exp ...
FAIL: ./systemtap.stress/current.stp startup (eof)
ERROR: tcl error sourcing ./systemtap.stress/current.exp.
ERROR: spawn_id: spawn id exp31 not open
     while executing
"close"
     (file "./systemtap.stress/current.exp" line 49)
     invoked from within
"source ./systemtap.stress/current.exp"
     ("uplevel" body line 1)

RE: Translator coverage of pass 5 testsuite

William Cohen wrote:
> Something is wrong with the systemtap.stress/current.exp on FC4. Which
> versions of the kernel did current.stp work with? It died with the FC4
> kernel:

I wrote that test, but I only tested it on RHEL4 U2 (2.6.9-22) and
U3beta (2.6.9-24).

> Looking through the output of "stap -g systemtap.stress/current.stp 
> -v -k" Lots of errors.

If you'll send me that log, I will take a look...

Thanks,

Josh

Re: Translator coverage of pass 5 testsuite

Stone, Joshua I wrote:
> William Cohen wrote:
> 
>>Something is wrong with the systemtap.stress/current.exp on FC4. Which
>>versions of the kernel did current.stp work with? It died with the FC4
>>kernel:
> 
> 
> I wrote that test, but I only tested it on RHEL4 U2 (2.6.9-22) and
> U3beta (2.6.9-24).
> 
> 
>>Looking through the output of "stap -g systemtap.stress/current.stp 
>>-v -k" Lots of errors.
> 
> 
> If you'll send me that log, I will take a look...

I have attached the output of "stap -g systemtap.stress/current.stp -v 
-k" to this email.

-Will

Created temporary directory "/tmp/stapMtaPys"
Searched '/home/wcohen/systemtap_write/src/tapset/2.6.14-1.1653_FC4/i686/*.stp', match count 0
Searched '/home/wcohen/systemtap_write/src/tapset/2.6.14-1.1653_FC4/*.stp', match count 0
Searched '/home/wcohen/systemtap_write/src/tapset/2.6.14/i686/*.stp', match count 1
Searched '/home/wcohen/systemtap_write/src/tapset/2.6.14/*.stp', match count 1
Searched '/home/wcohen/systemtap_write/src/tapset/2.6/i686/*.stp', match count 0

[Bug translator/2056] avoid locking within foreach iteration for maps & pmaps

--

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal
             Status|NEW                         |ASSIGNED
           Priority|P2                          |P1
   Last reconfirmed|0000-00-00 00:00:00         |2006-01-04 21:00:04
               date|                            |
            Summary|Cannot iterate pmaps        |avoid locking within foreach
                   |                            |iteration for maps & pmaps

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

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

RE: Translator coverage of pass 5 testsuite

William Cohen wrote:
> I have attached the output of "stap -g systemtap.stress/current.stp -v
> -k" to this email.

This is fixed now in CVS.  (current.stp r1.3)

Josh

[Bug translator/2056] avoid locking within foreach iteration for maps & pmaps

------- Additional Comments From hunt at redhat dot com  2006-01-05 06:08 -------
(In reply to comment #3)

> Regarding the pmap deadlock, one possible fix is to have foreach() iterating
> over a pmap hold an exclusive lock around the whole loop, and the  <at> extraction
> operators to hold none, when they're nested within foreach().  In fact, ordinary
> array reads enclosed within foreach() don't need to be locked either.  Let's
> transmute this bugzilla entry to track this bug.

Maybe I'm missing something, but the problem is the writelock.  Why does the
generated code take a writelock on the pmap when it is reading stats?

I suspect the reason is confusion over reading from a map and a pmap.  You need
a writelock when doing _stp_pmap_agg() or _stp_pmap_get().  However,
_stp_pmap_agg() creates a normal map and you only want to readlock it when reading.

Until this gets fixed, pmaps of stats are broken because we cannot print without
using foreach.

--

-- 

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

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

RE: Review patches of user space kprobe

The 4th patch is to avoid probes misses in smp environment. I just have
some initial comments because the patch is not complete.

See the inline comments below.

Yanmin

>>---
>>
>> linux-2.6.13-prasanna/arch/i386/kernel/kprobes.c |   52
++++++++++++++++++++---
>> 1 files changed, 46 insertions(+), 6 deletions(-)
>>
>>diff -puN arch/i386/kernel/kprobes.c~kprobes_avoid_smp_missprobes
arch/i386/kernel/kprobes.c
>>---
linux-2.6.13/arch/i386/kernel/kprobes.c~kprobes_avoid_smp_missprobes
2005-09-15 13:56:24.105192248 +0530
>>+++ linux-2.6.13-prasanna/arch/i386/kernel/kprobes.c	2005-09-15
13:56:24.137187384 +0530
>>+/*
>>+ * This routine provides the functionality of single stepping out of
line by
>>+ * copying the original instruction in the user process free stack
space.
>>+ */
>>+static inline int uprobe_single_step(struct uprobe *p, struct pt_regs
*regs)
>>+{
>>+	unsigned long page_addr, stack_addr = regs->esp;

tapset feedback

I have a bunch of issues with the current tapsets and the way tapsets
are implemented.  Others have written more tapsets than me and I'd
really like to know what your experiences are and what you think of the
following.

1. My biggest issue with the way tapsets are implemented is that there
are no namespaces or ways to limit the scope of a function. Plus the
concepts of code libraries and tapsets are overlapped.

Why is this a problem? Consider the functions contained in
aux_syscalls.stp. Some of these might be tempting for systemtap script
writers to use. However, some of these functions use embedded-C and are
safe to call only from certain contexts. Allowing any script writer to
use them bypasses our safety checks.

Secondly, we have a problem when two tapset writers mistakenly use the
same name for a function. This is a namespace issue that could be solved
by use of some simple naming convention. So it is not serious like the
first problem. But still an annoyance that needs addressing now, before
we have many people writing tapsets. And the solution for the first
problem might be able to solve both.

One thing I would recommend is a conceptual split between "tapsets",
which export probe points and a system library, which would export
general-purpose safe functions.

2. I am not running 2.6.14, 2.6.9-20.ELsmp, or 2.6.9-24.ELsmp on any of
my machines, so I cannot use the syscalls tapset. I mention this not to
pick on that tapset, but to point out that we have a serious maintenance
problem created by the way we have implemented tapsets.