Initial stap support for inode-based uprobes

Josh Stone jistone@redhat.com
Fri May 20 03:24:00 GMT 2011


The attached patch implements initial support for SystemTap to use
Srikar's inode-based uprobes.  It is also published in the branch
jistone/inode-uprobes, in gitweb here:
<http://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=shortlog;h=refs/heads/jistone/inode-uprobes>

The uprobes branch I worked from is here:
<http://git.kernel.org/?p=linux/kernel/git/srikar/linux-uprobes.git;a=shortlog;h=refs/heads/tip_inode_uprobes_010411>

The good news is that the basics appear to be working well.  I've tested
probing stap itself and libdw, and got the expected probe hits.  I'd
appreciate any review of my implementation so far.  Beyond these working
basics, there are a lot of details to hammer out, so here's the list of
what I know.

* EXPORT_SYMBOL_GPL, or uprobes' lack thereof.  Without kernel exports,
the whole API will be inaccessible to us.

* 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.


I think that's it.  So if you happen to build a kernel with the new
uprobes, please enjoy systemtap support too. :)

Josh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: systemtap-inode-uprobes.patch
Type: text/x-patch
Size: 14295 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20110520/2f5b79ef/attachment.bin>


More information about the Systemtap mailing list