Re: Initial stap support for inode-based uprobes

[David Smith <dsmith@redhat.com>]

I just got through running the systemtap testsuite on 2 different
configurations:

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
dejazilla:

<http://web.elastic.org/~dejazilla/viewrgdiff.php?rg1=402882&rg2=891228&_offset=0&_limit=40&_offset=0&testcase=&r1=&r2=>

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.


-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)