From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9333 invoked by alias); 27 Sep 2010 21:49:48 -0000 Received: (qmail 9294 invoked by uid 48); 27 Sep 2010 21:49:32 -0000 Date: Mon, 27 Sep 2010 21:49:00 -0000 Message-ID: <20100927214932.9293.qmail@sourceware.org> From: "mjw at redhat dot com" To: systemtap@sources.redhat.com In-Reply-To: <20100915213207.12026.wcohen@redhat.com> References: <20100915213207.12026.wcohen@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug runtime/12026] Revamp task_backtrace() to use same unwinder backtrace() X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2010-q3/txt/msg00466.txt.bz2 ------- 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.