about thread_info in task_struct

about thread_info in task_struct

[Wenji Huang]

Hi,

 First thank jim! I got the write access for systemtap.

 There is some change about task_struct in sched.h (since 2.6.22)

>Commit f7e4217b007d1f73e7e3cf10ba4fea4a608c603f
>Author: Roman Zippel <zippel@linux-m68k.org>
>Date:   Wed May 9 02:35:17 2007 -0700
>
>    rename thread_info to stack
>    
>    This finally renames the thread_info field in task structure to stack, so that
>    the assumptions about this field are gone and archs have more freedom about
>    placing the thread_info structure.

Therefor task_test.stp failed.  Reason in tapset/task.stp:

>  function task_cpu:long (task:long)
>  %( kernel_v >= "2.6.23" %?
>  %{ /* pure */
   ........

So maybe need a little modification, kernel_v >= "2.6.22" or using macro task_thread_info
 
Another, I wrote function for returning task addr in case of only knowing pid:

/*return task addr according to process id*/
function get_task: long (pid:long) %{
        struct task_struct *p;
        pid_t pid;
        pid = (pid_t)(long)THIS->pid;
        rcu_read_lock();
        p = find_task_by_pid(pid);
        rcu_read_unlock();
        THIS->__retvalue = (long) p;
        CATCH_DEREF_FAULT();
%}

Please review it. 

Best regards,
Wenji

RE: about thread_info in task_struct

[Stone, Joshua I]

Wenji Huang wrote:
> Another, I wrote function for returning task addr in case of only
> knowing pid:
> 
> /*return task addr according to process id*/
> function get_task: long (pid:long) %{
>         struct task_struct *p;
>         pid_t pid;
>         pid = (pid_t)(long)THIS->pid;
>         rcu_read_lock();
>         p = find_task_by_pid(pid);
>         rcu_read_unlock();
>         THIS->__retvalue = (long) p;
>         CATCH_DEREF_FAULT();
> %}

Mike Mason had something similar in the recent thread "Proposed task.stp additions".  The problem is that without calling get_task_struct(), you can't guarantee that the task pointer will remain valid.  We can possibly live with this, but scripts that use it might experience random dereference errors.

Also, you don't need CATCH_DEREF_FAULT(), because you aren't dereferencing any parameters with kread().

Josh