This is the mail archive of the mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Initial stap support for inode-based uprobes

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.

David Smith
Red Hat
256.217.0141 (direct)
256.837.0057 (fax)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]