[Bug runtime/12026] New: Revamp task_backtrace() to use same unwinder backtrace()

[Bug runtime/12026] New: Revamp task_backtrace() to use same unwinder backtrace()

[wcohen at redhat dot com]

The task_backtrace() uses it own unwinder mechanism in _stp_stack_print_tsk().
It looks like there could be some simplification if task_backtrace(), used the
machinery as backtrace(). It might also make the task_backtrace() work better
than the current version of task_backtrace().

A improved version of task_backtrace() would be very useful for improving the
performance of latencytap.

-- 
           Summary: Revamp task_backtrace() to use same unwinder backtrace()
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: wcohen at redhat dot com
OtherBugsDependingO 6960
             nThis:


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug runtime/12026] Revamp task_backtrace() to use same unwinder backtrace()

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2010-09-27 21:49 -------
function task_backtrace:string (task:long) defined in context-unwind.stp is
different from all other backtrace related functions like [[s]print][u]backtrace().

task_backtrace uses the function _stp_stack_[sn]print_tsk defined in stack.c and
only works when STAPCONF_KERNEL_STACKTRACE is defined true. This is the
in-kernel backtrace fallback which only works when there are frame pointers. All
other unwind related tapset functions go through _stp_stack_print (also from
stack.c). This uses the dwarf unwinder when possible and falls back to an
architecture specific unwinder or the in-kernel backtrace support when available.

Ideally task_backtrace, _stp_stack_[sn]print_tsk, would go through
_stp_stack_print also, so that it would invoke the dwarf unwinder. Currently
_stp_stack_print only works for the current task (if no task/NULL is given a
kernel backtrace is generated). This is because it needs to get a current set of
registers to init the dwarf unwinder state.

The register set comes either from CONTEXT->regs, if CONTEXT->regflags marks it
as valid for the current kernel/user space context. Or through
task_pt_regs(current). In the later case it uses _stp_task_pt_regs_valid from
runtime/compatdefs.h to check whether the register set is valid.

_stp_task_pt_regs_valid uses a very crude heuristic. It assumes the given task
== current, and if so (because the current task must have hit a probe point) the
register set returned by task_pt_regs(current) is valid if it the architecture
is i386, otherwise it is not. (See the XXX in the function comments for some
hints on improving on this.)

The above heuristic cannot really be used when using arbitrary tasks, since they
may be in any state (since they have not just been hitting a probe point). So
they may be running in either user or kernel space, so the register set you get
from task_pt_regs might not be current/sane.

It might be possible to just try to use the results of task_pt_regs and make the
result invalid (so the dwarf unwinder will use as little of the register set as
possible, see arch_unw_init_frame_info sanitize), and just hope for the best.
But this might give inaccurate/invalid/wrong backtraces.

Note that even if the register set is setup correctly the dwarf unwinder still
needs the unwind frame data of the task to function (for user space).

BTW. Double check security impact of this. Inspection of backtraces of tasks
not-owned by the user running the script should be disallowed.

-- 


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.