This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug tapsets/6525] need utrace task-finder-based pid->execname, pid->cwd-path-name tables
- From: "dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 2 Mar 2009 14:55:48 -0000
- Subject: [Bug tapsets/6525] need utrace task-finder-based pid->execname, pid->cwd-path-name tables
- References: <20080516134833.6525.fche@redhat.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From dsmith at redhat dot com 2009-03-02 14:55 -------
(In reply to comment #5)
> I once tried to implement the functions using task_finder. The basic code is
> like the following
>
> #include "task_finder.c"
> static char _stp_taskname[TASK_COMM_LEN]="";
> static int _stp_process_search_cb(struct stap_task_finder_target *tgt, struct
> task_struct *tsk, int register_p, int process_p) {
> if (register_p) { /* found one match */
> if (tsk == NULL) {
> strlcpy(_stp_taskname, "UNKNOWN", MAXSTRINGLEN);
> return 1;
> } else {
> strlcpy(_stp_taskname, tsk->comm, MAXSTRINGLEN);
> return 0;
> }
> }
> return 1;
> }
>
> function pid2execname2:string(pid:long) %{ /* pure */
> struct stap_task_finder_target tgt;
> tgt.pathname = NULL;
> tgt.pid = (pid_t)(long)THIS->pid;
> tgt.callback = &_stp_process_search_cb;
> tgt.vm_callback = NULL;
> stap_register_task_finder_target(&tgt);
> stap_start_task_finder();
> strlcpy(THIS->__retvalue, _stp_taskname, MAXSTRINGLEN);
> stap_stop_task_finder();
> CATCH_DEREF_FAULT();
> %}
>
> But it can't return the execname of most running processes like init, mingetty,
> kjournald because the callback is never invoked.
> Only works fine on my forked test process. My box is 2.6.27.9-159.fc10.i686.
The task_finder will never be able to return the execname or pathname of kernel
threads, like 'init' or 'kjournald'. The 'u' in 'utrace' stands for 'user' - it
only works on user threads. I'm unsure of why 'mingetty' couldn't be found.
> Did I miss something or misunderstand the mechanism?
Besides the above problem of returning the execname/pathname for kernel threads,
there are other things that won't work well in the code you posted. As
currently written, the task_finder isn't designed to register new targets while
running (since there is no locking provided) or to be started/stopped more than
once.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6525
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.