[Bug tapsets/12413] kprocess.* support PIDs but not TIDs

[Bug tapsets/12413] kprocess.* support PIDs but not TIDs

[dsmith at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12413

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |dsmith at redhat dot com
         Resolution|FIXED                       |

--- Comment #2 from David Smith <dsmith at redhat dot com> 2011-12-13 22:28:11 UTC ---
It looks like this fix doesn't work (and we didn't notice until now since the
build testcase wasn't updated to include the new variables):

# stap -L 'kprocess.release'
semantic error: unable to find member 'tid' for struct task_struct
(alternatives: state stack usage flags ptrace lock_depth prio static_prio
normal_prio rt_priority sched_class se rt preempt_notifiers fpu_counter
btrace_seq policy cpus_allowed sched_info tasks pushable_tasks mm active_mm
exit_state exit_code exit_signal pdeath_signal personality did_exec in_execve
in_iowait sched_reset_on_fork pid tgid stack_canary real_parent parent children
sibling group_leader ptraced ptrace_entry pids thread_group vfork_done
set_child_tid clear_child_tid utime stime utimescaled stimescaled gtime
prev_utime prev_stime nvcsw nivcsw start_time real_start_time min_flt maj_flt
cputime_expires cpu_timers real_cred cred cred_guard_mutex
replacement_session_keyring comm link_count total_link_count sysvsem
last_switch_count thread fs files nsproxy signal sighand blocked real_blocked
saved_sigmask pending sas_ss_sp sas_ss_size notifier notifier_data
notifier_mask audit_context loginuid sessionid seccomp utrace utrace_flags
parent_exec_id self_exec_id alloc_lock irqaction pi_lock pi_waiters
pi_blocked_on blocked_on irq_events hardirqs_enabled hardirq_enable_ip
hardirq_enable_event hardirq_disable_ip hardirq_disable_event softirqs_enabled
softirq_disable_ip softirq_disable_event softirq_enable_ip softirq_enable_event
hardirq_context softirq_context curr_chain_key lockdep_depth lockdep_recursion
held_locks lockdep_reclaim_gfp journal_info bio_list bio_tail reclaim_state
backing_dev_info io_context ptrace_message last_siginfo ioac acct_rss_mem1
acct_vm_mem1 acct_timexpd mems_allowed cpuset_mem_spread_rotor
cpuset_slab_spread_rotor mems_allowed_change_disable cgroups cg_list
robust_list compat_robust_list pi_state_list pi_state_cache __reserved_perf__
perf_event_mutex perf_event_list mempolicy il_next fs_excl rcu splice_pipe
delays make_it_fail dirties latency_record_count latency_record timer_slack_ns
default_timer_slack_ns scm_work_list curr_ret_stack ret_stack ftrace_timestamp
trace_overrun tracing_graph_pause trace trace_recursion rh_reserved
perf_event_ctxp): operator '->' at
/usr/local/share/systemtap/tapset/kprocess.stp:120:22
        source:     released_tid = $p->tid;
                                     ^
semantic error: unresolved type : identifier 'released_tid' at :120:5
        source:     released_tid = $p->tid;
                    ^
kprocess.release task:long pid:long released_pid:long released_tid:unknown
$p:struct task_struct*


I'm thinking:

=========
probe kprocess.release = kernel.function("release_task") {
    task = $p
    pid = $p->pid;
    released_pid = $p->pid;
    released_tid = $p->tid;
}
=========

Should be changed to:

=========
probe kprocess.release = kernel.function("release_task") {
    task = $p
    pid = task_pid($p)
    released_pid = task_pid($p)
    released_tid = task_tid($p)
}
=========

We also might think about really deprecating 'pid' (since 'released_pid' seems
to replace it).

We'll also need the testcase updated.

Does the above look reasonable?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug tapsets/12413] kprocess.* support PIDs but not TIDs

[dsmith at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12413

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |13501

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug tapsets/12413] kprocess.* support PIDs but not TIDs

[dsmith at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12413

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from David Smith <dsmith at redhat dot com> 2011-12-15 15:50:51 UTC ---
Fixed in commit 2cf2514.  The 'pid' variable is properly deprecated and the
'released_pid' and 'released_tid' variables now work correctly.  The
kprocess.release build testcase was also updated.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug tapsets/12413] New: kprocess.* support PIDs but not TIDs

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12413

           Summary: kprocess.* support PIDs but not TIDs
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
        AssignedTo: systemtap@sources.redhat.com
        ReportedBy: jan.kratochvil@redhat.com


Created attachment 5201
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5201
untested fix

One cannot provide thread-specific tracing this way.
I had to call task_tid(task) in the .stp script.

Also while kprocess.create differentiates current context from the created
process by >new_<pid kprocess.release uses just plain pid, not >released_<pid,
despite the context may be different from the released task.  I found it a bit
non-systematic.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug tapsets/12413] kprocess.* support PIDs but not TIDs

[wcohen at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12413

William Cohen <wcohen at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |wcohen at redhat dot com
         Resolution|                            |FIXED

--- Comment #1 from William Cohen <wcohen at redhat dot com> 2011-01-20 21:43:43 UTC ---
Fixed in the following commit:

commit 58ef33dba6cbba9638476020e8055877ae2ffabd
Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Date:   Thu Jan 20 16:40:26 2011 -0500

    PR12413, Provide TID information in kprocess.create and kprocess.release

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.