[Bug tapsets/6525] New: need utrace task-finder-based pid->execname, pid->cwd-path-name tables

[Bug tapsets/6525] New: need utrace task-finder-based pid->execname, pid->cwd-path-name tables

[fche at redhat dot com]

We need a tapset that uses the new task-finder runtime in order to populate and
maintain systemtap script-level globals/functions that allow pid-based data lookup.

Specifically:

function pid2execname:string (pid:long) {}
function pid2cwdpath:string (pid:long) {}
... and maybe more.

These functions could be implemented as embedded-c or script, using globals
that are managed by utrace task-finder callback functions notifying the tapset
of tasks running chdir()/chroot()/exec().  To initially populate the globals
(for preexisting processes), the embedded-c code would need to use possibly
sleepy kernel functions to process task_struct*'s.

-- 
           Summary: need utrace task-finder-based pid->execname, pid->cwd-
                    path-name tables
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: fche at redhat dot com


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.

[Bug tapsets/6525] need utrace task-finder-based pid->execname, pid->cwd-path-name tables

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-01-15 18:56 -------
Similarly, pid2argv:string (pid:long, argn:long) {}
from which command-line argument-based filtering.

-- 


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.

[Bug tapsets/6525] need utrace task-finder-based pid->execname, pid->cwd-path-name tables

[wenji dot huang at oracle dot com]

------- Additional Comments From wenji dot huang at oracle dot com  2009-02-26 08:08 -------
Regarding pid2execname, find_task_by_vpid/pid may be better candidate for
implementation of the lookup function.

-- 


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.

[Bug tapsets/6525] need utrace task-finder-based pid->execname, pid->cwd-path-name tables

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-02-26 08:14 -------
(In reply to comment #2)
> Regarding pid2execname, find_task_by_vpid/pid may be better candidate for
> implementation of the lookup function.

Right, as long as find_task_XXX may be invoked from atomic context.


-- 


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.

[Bug tapsets/6525] need utrace task-finder-based pid->execname, pid->cwd-path-name tables

[wenji dot huang at oracle dot com]

------- Additional Comments From wenji dot huang at oracle dot com  2009-02-26 09:17 -------
Created an attachment (id=3771)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=3771&action=view)
lookup functions pid2task and pid2execname based on find_task_by_* 


-- 


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.

[Bug tapsets/6525] need utrace task-finder-based pid->execname, pid->cwd-path-name tables

[wenji dot huang at oracle dot com]

------- Additional Comments From wenji dot huang at oracle dot com  2009-02-26 09:35 -------
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.

Did I miss something or misunderstand the mechanism?


-- 


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.

[Bug tapsets/6525] need utrace task-finder-based pid->execname, pid->cwd-path-name tables

[dsmith at redhat dot com]

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

[Bug tapsets/6525] need utrace task-finder-based pid->execname, pid->cwd-path-name tables

[wenji dot huang at oracle dot com]

------- Additional Comments From wenji dot huang at oracle dot com  2009-03-03 04:29 -------
(In reply to comment #6)
> > 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.
> 
Thank you for letting me know this. Seems task_finder is not good candidate
for pid lookup functions. Maybe my patch in #4 is a choice.


-- 


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.