This is the mail archive of the
mailing list for the systemtap project.
Re: Initial stap support for inode-based uprobes
- From: David Smith <dsmith at redhat dot com>
- To: Josh Stone <jistone at redhat dot com>
- Cc: systemtap at sourceware dot org, Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>
- Date: Wed, 16 Nov 2011 11:39:34 -0600
- Subject: Re: Initial stap support for inode-based uprobes
- References: <4DD5DEAA.email@example.com>
I just got through running the systemtap testsuite on 2 different
1) stock f16 kernel and HEAD systemtap
# of expected passes 3096
# of unexpected failures 63
# of unexpected successes 8
# of expected failures 259
# of untested testcases 61
# of unsupported tests 4
2) f16 kernel with the new inode-based uprobes built-in and systemtap
with a merged dsmith/task_finder2 and jistone/inode-uprobes branches
# of expected passes 2638
# of unexpected failures 329
# of unexpected successes 9
# of expected failures 251
# of untested testcases 70
# of unsupported tests 4
That isn't too bad for a first stab. Here's the link to the diff in
I haven't had time to do a full analysis of the results, but the
problems Josh listed in his original email (included below) are still there.
> * Return probes. This hasn't yet been added to the new uprobes.
> * Process filtering. AFAICS, the current uprobes implementation sets
> the breakpoint in all processes that map the particular inode. There is
> a filtering mechanism, but that seems only to decide whether to call the
> handler each time. You'll still take the bp/sstep overhead. Also, on
> stap's side, we previously had the ability to limit process probes to
> the -x/-c target and children, which I haven't tried here yet.
> * Runtime build-id verification. Right now I'm just mapping the path to
> inode*, without checking that the build-id is what we expected. I'm not
> sure we even could at the systemtap-init point. Even if we did, the
> file may still get modified without changing the inode, and I don't
> think this uprobes gives us any way to notice or decide whether we like
> the new form.
> * SDT semaphore. In the current form, we have no hook on individual
> processes, so we can't modify the semaphores in applications that are
> actively gating their markers. We'll probably need something like
> PR10994 to achieve this, which isn't really about uprobes per-se, but
> rather about living without utrace.
> * Argument access. If you try $args, it will fail with a missing symbol
> 'task_user_regset_view'. I haven't looked closely at this yet.
> * Probe IP. For many probe handlers, we try to set the pt_regs IP to
> the actual breakpoint IP, but in this case we don't happen to even know
> the virtualized address. Uprobes itself uses uprobes_get_bkpt_addr() in
> some instances, but that's not exposed for our use.