Shutting down this list?
Hi, The last message to this list was in March (and was really a question about systemtap, not utrace). As far as I know nobody has ported utrace to the latest stable 3.5 mainline kernel. So it might be time to close this list (keeping the archives of course). I don't mind keeping it open, but currently all it seems to attract is spam messages that need to be moderated. Unless I see an objection or a real message on this list in the next couple of weeks time I'll switch this list to read-only. Thanks, Mark
Re: utrace for linux-2.6.38
On Wed, 2011-07-27 at 10:24 +0800, Wu, Jabin wrote: Hi Mr./Mrs., Very sorry for bothering you! If it is allowed, may I ask if utrace supports linux-2.6.38 at the moment and where can I get the patch. utrace for some releases can be found at http://userweb.kernel.org/~frob/utrace/ There is a 2.6.38 patch inside the fedora kernel git tree: http://pkgs.fedoraproject.org/gitweb/?p=kernel.git;a=tree;h=refs/heads/f15;hb=refs/heads/f15 And Oleg recently posted a port to 3.0 on this list: https://www.redhat.com/archives/utrace-devel/2011-July/msg0.html Cheers, Mark
Re: UTRACE PATCHES NEEDED
On Wed, 2011-06-08 at 11:35 +0530, Pradeep Chhetri wrote: I am currently working on systemtap trying to extract information from a userspace application which is running somewhere remotely. I am not able to configure my kernel for that. You might also want to ask on the systemtap mailinglist. system...@sourceware.org I am able to extract the kernel space data. My machine is having kernel version 2.6.35. I want to know the patches of utrace which are needed for my kernel and the required configuration steps for that. Patch series can be found here: http://userweb.kernel.org/~frob/utrace/ I searched online a lot but didn't get any proper documentation for userspace application monitoring. utrace just provides the kernel layer to make userspace monitoring easier. You need tools that take advantage of it, like systemtap, to do the actual observing. I would be nice for me if you can provide me the link of the documentation for utrace configuration See also the wiki: http://sourceware.org/systemtap/wiki/utrace Cheers, Mark
Re: utrace support on ARM
utrace per se has no machine-dependent code. It requires modern support for machine dependencies in generic kernel code, i.e. user_regset and tracehook. The ARM kernel has a tiny subset of those, but not enough to be useful. Long ago I did 98% of the work for implementing user_regset and tracehook support for ARM and posted it This is the patch set Roland refers to if someone wants to help push arm forward: http://lkml.org/lkml/2009/4/24/383 Cheers, Mark
RE: utrace support on ARM
Hi Turgis, On Wed, 2011-04-20 at 10:00 +0200, Turgis, Frederic wrote: * utrace has not been accepted upstream. Does it mean it may lose traction ? Is community pushing for something else or happy with what they have ? Parts haven't. utrace builds upon regsets and tracehooks, which are both in the mainline kernel already. But the answer is both. Lots of distros ship kernels with utrace enabled already. But there is also... * I have also found IBM presentation on utrace-less uprobes. How does it affect utrace ? It doesn't affect it directly. It is just another way to have user space probes working (but without the easy task triggers). So projects that now use a combination of utrace and uprobes will have to adjust a little to work without the easy taks level triggers that utrace brings and use the page level triggers that the new uprobes proposal has. Cheers, Mark
Re: utrace support on ARM
On Tue, 2011-03-29 at 16:26 +0200, Turgis, Frederic wrote: - http://people.redhat.com/roland/utrace is no longer valid. Where has it been moved ? http://userweb.kernel.org/~frob/utrace/ - Mail archive in https://www.redhat.com/archives/utrace-devel/ stops in December. Did I miss something ? No, that is right. It should now have two new emails in March :) Cheers, Mark
Re: Need information on utrace based user space API
On Thu, 2010-12-02 at 21:15 +0100, Pavan wrote: I am new to utrace and want to use it for instruction tracing user space applications. Can some one please help me with this ? I have read about uprobes, but am unable to get more details on how can i get it and how can i use it. Any help will be really appreciated. Systemtap has an probe process().insn[.block] that is based on UTRACE_SINGLESTEP / BLOCKSTEP: http://sourceware.org/systemtap/langref/Probe_points.html#SECTION00065700 The systemtap source code also contains an (actually two) implementation of uprobes based on utrace: http://sourceware.org/git/?p=systemtap.git;a=tree;f=runtime/uprobes2 Also look in the archives of this list and/or the lkml mailinglist for another version not currently based on utrace. Cheers, Mark
Re: Need help on utrace
On Tue, 2010-11-30 at 22:36 +0100, Pavan wrote: I am new to utrace and want to know is there any way i can get an Linux ISO image with utrace ? Please help. I need it for my coursework. utrace is included in a couple of distros by default. Fedora, CentOS, Red Hat Enterprise Linux and OpenSuse (you need the kernel-trace package) come with utrace build in.
Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
On Mon, 2010-01-18 at 14:53 +0200, Avi Kivity wrote: On 01/18/2010 02:51 PM, Pekka Enberg wrote: And how many probes do we expected to be live at the same time in real-world scenarios? I guess Avi's one million is more than enough? I don't think a user will ever come close to a million, but we can expect some inflation from inlined functions (I don't know if uprobes replicates such probes, but if it doesn't, it should). SystemTap by default places probes on all instances of an inlined function. It is still hard to get to a million probes though. $ stap -v -l 'process(/usr/bin/emacs).function(*)' [...] Pass 2: analyzed script: 4359 probe(s) You can try probing all statements (for every function, in every file, on every line of source code), but even that only adds up to ten thousands of probes: $ stap -v -l 'process(/usr/bin/emacs).statement(*...@*:*)' [...] Pass 2: analyzed script: 39603 probe(s) So a million is pretty far out, even if you add larger programs and all the shared libraries they are using. As Srikar said the current allocation technique is the simplest you can do, one xol slot for each uprobe. But there are other techniques that you can use. Theoretically you only need a xol slot for each thread of a process that simultaneously hits a uprobe instance. That requires a bit more bookkeeping. The variant of uprobes that systemtap uses at the moment does that. But the locking in that case is pretty tricky, so it seemed easier to first get the code with the simplest xol allocation technique upstream. But if you do that than you can use a very small xol area to support millions of uprobes and only have to expand it when there are hundreds of threads in a process all hitting the probes simultaneously. Cheers, Mark
Re: [RFC] [PATCH 7/7] Ftrace plugin for Uprobes
On Thu, 2010-01-14 at 12:29 +0100, Peter Zijlstra wrote: On Thu, 2010-01-14 at 12:23 +0100, Peter Zijlstra wrote: On Mon, 2010-01-11 at 17:56 +0530, Srikar Dronamraju wrote: This patch implements ftrace plugin for uprobes. Right, like others have said, trace events is a much saner interface. So the easiest way I can see that working is to register uprobes against a file (not a pid). Just to clarify, this means you can do things like: p:uprobe_event dso:symbol[+offs] Irrespective of whether there are any current user of that file. Yes, that is a good idea, you can then also refine that with a filter on a target pid. That is what systemtap also does, you define files (whether they are executables or shared libraries, etc) plus symbols/offsets/etc as targets and monitor when they get mapped in (either system wide, per executable or pid based). Cheers, Mark
Re: [PATCH] For selinux sake allocate a fake unlinked shmem
Hi Srikar, On Fri, 2009-09-25 at 19:42 +0530, Srikar Dronamraju wrote: We allocate a fake unlinked shmem file because anonymous memory might not be granted execute permission when the selinux security hooks have their way. Signed-off-by: Srikar Dronamraju sri...@linux.vnet.ibm.com Signed-off-by: Mark Wielaard m...@redhat.com Many thanks for forward porting it. I kept being busy with other stuff to do it myself. Looks good to me. Thanks, Mark
Re: x86 single-step issues
Hi Roland, On Wed, 2008-07-09 at 14:28 -0700, Roland McGrath wrote: Are all the bugs you've encountered related to single-step covered in the ptrace-tests suite? I have some more fixes in the x86 bowels about ready to send upstream. From the status quo upstream, my changes get FAIL-PASS for step-jump-cont-strict (32 64), step-through-sigret (32). There are no step-related failures left in 'make check -sk' on i686 or x86_64 kernels (including both tests biarch-tests). Does that cover all the issues you know about? Yes it does. They correspond to the following Fedora kernel bugs: https://bugzilla.redhat.com/show_bug.cgi?id=441406 https://bugzilla.redhat.com/show_bug.cgi?id=450379 Cheers, Mark
Step through signal (sigret)
Hi,
I wrote a little test for the ptrace-testsuite that I believe should
PASS. It does PASS on x86_64 (2.6.24.4-64.fc8) and some older x86
(2.6.20-1.2933.fc6) kernels. It doesn't on a recent fedora 8 kernel for
x86 (2.6.24.4-64.fc8).
The test waits for a signal in the child, and then uses ptrace
singlestep to go through the signal handler setup in the child till the
process returns to where it was interrupted. In the failing case at the
sigret syscall the child process runs free instead of single stepping.
Questions:
- If the testcase looks sane, and it is expected that a singlestep never
sets the child process running free, could this test be added to the
ptrace-testsuite?
- If the assumption/test is wrong, then what is the expected behavior?
Should the tracing process watch for special syscalls and manipulate the
sigcontext on the stack to explicitly set the stepping flag? (This seems
to be what gdb does.) Are there other special sigcalls?
Thanks,
Mark
Successful run (2.6.24.4-64.fc8 x86_64):
$ ./tests/step-through-sigret -v
#parent (#63) forking
#child (#71) Setting up handler and alarm
#child (#82) spinning till signal...
#parent (#94) ptrace attach
#parent (#98) wait for attach
#parent (#105) let child run free (till signal)
#parent (#109) waiting for child SIGALRM
#parent (#117) child got signal at 0x400e48
#parent (#120) do first step into signal handler
#parent (#131) stepped into sig_handler (0x400750)
#parent (#137) single step child (0x400750)
#parent (#137) single step child (0x40075a)
#parent (#137) single step child (0x3a16830f30)
#parent (#137) single step child (0x3a16830f37)
#parent (#150) done stepping sig_handler (0x400e48)
#parent (#153) Let child run free (till exit)
#parent (#157) waiting for child exit
#child (#86) done
#parent (#163) done
Failing run (2.6.24.4-64.fc8 x86):
$ tests/step-through-sigret -v
#parent (#63) forking
#child (#71) Setting up handler and alarm
#child (#82) spinning till signal...
#parent (#94) ptrace attach
#parent (#98) wait for attach
#parent (#105) let child run free (till signal)
#parent (#109) waiting for child SIGALRM
#parent (#117) child got signal at 0x8048dbe
#parent (#120) do first step into signal handler
#parent (#131) stepped into sig_handler (0x8048590)
#parent (#137) single step child (0x8048590)
#parent (#137) single step child (0x8048591)
#parent (#137) single step child (0x8048593)
#parent (#137) single step child (0x8048594)
#parent (#137) single step child (0x804859e)
#parent (#137) single step child (0x110420)
#parent (#137) single step child (0x110421)
#parent (#137) single step child (0x110426)
#child (#86) done
step-through-sigret: step-through-sigret.c:143: main: Assertion
`__extension__ ({ union { __typeof(status) __in; int __i; } __u;
__u.__in = (status); __u.__i; }))) 0xff) == 0x7f)' failed.
Aborted
// Tests whether we can ptrace single step through a child signal
// handler and return where the signal interrupted the child
// afterwards. In particular tests whether we can single step over the
// sigret syscall at the end of the handler. On some kernels
// (e.g. 2.6.24.4-64.fc8 x86) this cleared the stepping flag and let
// the child run free.
//
// Author: Mark Wielaard [EMAIL PROTECTED]
#include assert.h
#include stdio.h
#include stdlib.h
#include unistd.h
#include sys/ptrace.h
#include sys/types.h
#include sys/user.h
#include sys/wait.h
#ifdef __i386__
#define PC eip
#endif
#ifdef __x86_64__
#define PC rip
#endif
#ifndef PC // unsupported architecture
int main (int argc, char **argv) { return 77; }
#else
// The process to trace.
static pid_t pid = -1;
// Whether to be verbose (just give any argument to the program).
static int verbose;
#define VERBOSE(output...) do { if (verbose) { \
printf (#%s (#%d) , (pid != 0 ? parent : child), __LINE__); \
printf (output); \
} } while (0)
// Signal ran and process done?
static volatile int done = 0;
// When SIGALRM comes in set done flag. Nothing interesting,
// we are just interested in stepping through it, including the sigret.
static void sig_handler(int sig) { done = 1; }
// Returns the current pc value of the child pid (must be stopped).
static long int
get_pc(int pid)
{
struct user_regs_struct regs;
long r = ptrace (PTRACE_GETREGS, pid, NULL, regs);
assert (r != -1);
return regs.PC;
}
int
main (int argc, char **argv)
{
verbose = (argc 1);
VERBOSE (forking\n);
pid = fork ();
assert (pid != -1);
switch (pid)
{
case 0:
{
// Child, sets up a sigalrm handler, sets the alarm and spins.
VERBOSE (Setting up handler and alarm\n);
struct sigaction sa;
sa.sa_handler = sig_handler;
int r = sigemptyset(sa.sa_mask);
assert (r == 0);
sa.sa_flags = 0;
r = sigaction(SIGALRM, sa, NULL);
assert (r == 0);
r = alarm(1);
assert (r == 0);
VERBOSE (spinning till signal...\n);
while (! done)
/* do something */ ;
VERBOSE (done\n);
exit (0);
}
default:
{
// Parent, attched to child, waits for signal
