headers
Stone, Joshua I | 1 Feb 2006 01:17
Picon
Favicon

RE: rethinking syscall tapset

James Dickens wrote:
> I don't see a reason to combine both call and return in one block, but
> I think it would be nice to be able to access all the arguments used
> to call a syscall, in a way that require each syscall written
> individually and that is architecturally transparent.
> 
> probe syscall.* {
>     printf(%s ( "%s called with %X(%d), %X(%d) ",   probename,  arg0,
> arg0, arg1, arg1 );
> }
> 
> this type of script can be quite useful and is much lighter on the
> system than strace that only plays games  stopping the application at
> each syscall.

This generic variable-naming is the way Dtrace does things, but I'm not
sure how much that really buys you...

Your toy script is only useful for functions that have two integer
arguments.  Plus, anything with a pointer is not very informative.  It
would be possible for the syscall tapset to load arg0, arg1, etc. with
the string representations of each parameter, but then you need to know
how many arguments to read.  So really, you're back to the 'argstr' that
Martin proposed already...

Josh
Permalink | Reply | 1 comment |
headers
joshua dot i dot stone at intel dot com | 1 Feb 2006 01:23
Favicon

[Bug translator/2252] stap generated code does not compile on RHEL4 UP kernel


--

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joshua dot i dot stone at
                   |                            |intel dot com

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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
James Dickens | 1 Feb 2006 03:04
Picon

Re: rethinking syscall tapset

On 1/31/06, Stone, Joshua I <joshua.i.stone <at> intel.com> wrote:
> James Dickens wrote:
> > I don't see a reason to combine both call and return in one block, but
> > I think it would be nice to be able to access all the arguments used
> > to call a syscall, in a way that require each syscall written
> > individually and that is architecturally transparent.
> >
> > probe syscall.* {
> >     printf(%s ( "%s called with %X(%d), %X(%d) ",   probename,  arg0,
> > arg0, arg1, arg1 );
> > }
> >
> > this type of script can be quite useful and is much lighter on the
> > system than strace that only plays games  stopping the application at
> > each syscall.
>
> This generic variable-naming is the way Dtrace does things, but I'm not
> sure how much that really buys you...
>
> Your toy script is only useful for functions that have two integer
> arguments.  Plus, anything with a pointer is not very informative.  It
> would be possible for the syscall tapset to load arg0, arg1, etc. with
> the string representations of each parameter, but then you need to know
> how many arguments to read.  So really, you're back to the 'argstr' that
> Martin proposed already...
>
it doesn't need to know the exact number, you support upto 10
arguments, if they aren't used, it will return bogus data. but it does
allow to get the data quickly and easily. The same type of thing also
should be supported with userland probes. Where in a lot of cases we
(Continue reading)

Permalink | Reply | 0 comments |
headers
Masami Hiramatsu | 1 Feb 2006 14:02
Picon

Re: [PATCH] kretprobe: kretprobe-booster against 2.6.16-rc1 for i386

Hi, Andrew
Andrew Morton wrote:
> Masami Hiramatsu <hiramatu <at> sdl.hitachi.co.jp> wrote:
>>-	regs->eip = orig_ret_address;
>>
>>-	reset_current_kprobe();
>> 	spin_unlock_irqrestore(&kretprobe_lock, flags);
>>-	preempt_enable_no_resched();
>
> Again, the patch removes a preempt_enable() and doesn't add a
> preempt_disable().  Maybe this is to balance the earlier patch.  If so,
> they should both be in the same patch so the kernel works OK at each stage.
> You didn't include a description of what this patch actually does.

That is not to balance the previous patch. Here is the reason and
the description of kretprobe-booster.

The kretprobe basically invokes kprobe twice as following actions;

At function entrance:
(1) int3 (1st kprobe)
(2) preempt_disable
(3) call pre_handler_kretprobe ()
(3-1) store original return address to a retprobe instance
(3-2) modify return address.
(4) copied instructioin(single step)
(5) preempt_enable

At function exit:
(1) return to kretprobe_trampoline
(Continue reading)

Permalink | Reply | 0 comments |
headers
Masami Hiramatsu | 1 Feb 2006 14:02
Picon

Re: [PATCH][2/2] kprobe: kprobe-booster against 2.6.16-rc1 for i386

Hi, Andrew
Andrew Morton wrote:
> These preempt tricks look rather nasty.  Can you please describe what the
> problem is, precisely?  And how this code avoids it?  Perhaps we can find
> something cleaner.

The problem is how to remove the copied instructions of the
kprobe *safely* on the preemptable kernel (CONFIG_PREEMPT=y).

Kprobes basically executes the following actions;

(1)int3
(2)preempt_disable()
(3)kprobe_prehandler()
(4)copied instructioin(single step)
(5)kprobe_posthandler()
(6)preempt_enable()
(7)return to the original code

During the execution of copied instruction, preemption is
disabled (from step (2) to (6)).
When unregistering the probes, Kprobe waits for RCU
quiescent state by using synchronize_sched() after removing
int3 instruction.
Thus we can ensure the copied instruction is not executed.

On the other hand, kprobe-booster executes the following actions;

(1)int3
(2)preempt_disable()
(Continue reading)

Permalink | Reply | 0 comments |
headers
William Cohen | 1 Feb 2006 17:42
Picon
Favicon

Results of tests on nightly builds

I have a cron job set up on a number of machines to run the systemtap 
tests each night to see how things are working (or broken). Here are the 
results of the tests.

-Will

Summarize the results of nightly test run Feb 1 2006.

The pmap_agg_overflow tests requires smp machines so on the single
processor machines it ends up being unsupported.

FC4 i686 UP Linux 2.6.14-1.1656_FC4

buildok-six.stp: unable to resolve kernel.inline("context_switch") on
	Linux 2.6.14-1.1656_FC4

		=== systemtap Summary ===

# of expected passes		127
# of unsupported tests		1

FC5 i686 SMP Linux 2.6.15-1.1884_FC5smp

buildok-seven.stp: unable to find indentifiers $type and $task

Testsuite summary of failed tests
FAIL: ./systemtap.maps/ix_hist.stp timed out (PASSED when run by hand??!)
FAIL: profile (timeout) (looks like dependent times out because of jiffies)
FAIL: profile
		=== systemtap Summary ===
(Continue reading)

Permalink | Reply | 1 comment |
headers
Frank Ch. Eigler | 1 Feb 2006 19:24
Picon
Favicon
Gravatar

Re: Results of tests on nightly builds


wcohen wrote:

> [...]
> semok-twenty.stp very strange couldn't find debuginfo [...]
> semantic error: cannot find module stap_18875 debuginfo: No such file
> or directory

This indicates that there was already a systemtap probe left running
when the next one came along.  Since semok/twenty.stp attempts to
enumerate "kernel.module("*")", the prior systemtap module is also
selected for analysis.  elfutils couldn't find its debug information,
since it is only to be found under /tmp/ someplace.

- FChE
Permalink | Reply | 0 comments |
headers
Martin Hunt | 1 Feb 2006 20:26
Picon
Favicon

kprobes versioning?

Is there some way to tell what version of kprobes a kernel is running?

For example, the kretprobe sys_execve bug has been fixed and 2.6.15 has
the fix in it. So do RHEL4 kernels after 2.6.9-17. All other kernels,
including the non-test FC4 kernels do not have it and many of my syscall
tests crash the kernel. 

So sys_execve should be back on the blacklist, but what to check for?
The problem is only going to get worse as kprobes changes rapidly with
kprobe-booster, djprobes, and user probes. There will be probably bugs
in some versions and new features will become available.  People will
want to backport these fixes and features into older kernels.

Martin
Permalink | Reply | 0 comments |
headers
Martin Hunt | 1 Feb 2006 21:31
Picon
Favicon

new syscall tapset checked in, but needs work

I've checked in 4 files in stp/src/tapset

I'm working on these
syscalls.stp          (sys_[a-m]*)
x86_64/syscalls.stp

Hien, can you take these?
syscalls2.stp         (sys_[n-z]*)
i686/syscalls.stp

Here's a quick script to test with:

probe syscall.*, syscall.*.return {
        if (pid() == target()) {
                if (returnp)
                        printf("%d\n", returnval())
                else
                        printf("%s (%s) = ", name, argstr)
        }
}

> stap -c bash sys.stp
execve () = 0
brk (0x0) = 165474304
access ("/etc/ld.so.preload", F_OK|R_OK) = -2
open ("/etc/ld.so.cache", O_RDONLY) = 4
open ("/lib/libtermcap.so.2", O_RDONLY) = 4
read (4, ..., 512) = 512
open ("/lib/libdl.so.2", O_RDONLY) = 4
read (4, ..., 512) = 512
(Continue reading)

Permalink | Reply | 2 comments |
headers
fche at redhat dot com | 1 Feb 2006 21:40
Favicon

[Bug translator/2205] Systemtap parser will fall into infinite loop.


------- Additional Comments From fche at redhat dot com  2006-02-01 20:40 -------
By the way, labeling bugs like this one as "critical" is not really appropriate.
 The translator hanging on input with guru-mode syntax errors is not that
severe/important a problem.

--

-- 

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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |

Gmane