From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: "Tu, Xiaobing" <xiaobing.tu@intel.com>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"mingo@elte.hu" <mingo@elte.hu>,
"rusty@rustcorp.com.au" <rusty@rustcorp.com.au>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"yanmin_zhang@linux.intel.com" <yanmin_zhang@linux.intel.com>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"Zuo, Jiao" <jiao.zuo@intel.com>
Subject: Re: [RFC 1/2] kernel patch for dump user space stack tool
Date: Fri, 20 Apr 2012 11:44:33 +0200 [thread overview]
Message-ID: <1334915073.2463.36.camel@laptop> (raw)
In-Reply-To: <EE928378561BF1449699C96571234A740FCE3704@SHSMSX102.ccr.corp.intel.com>
On Wed, 2012-04-11 at 08:07 +0000, Tu, Xiaobing wrote:
> From: xiaobing tu <xiaobing.tu@intel.com>
>
> Here is the kernel patch for this tool, The idea is to output user
> space stack call-chain from /proc/xxx/stack,
> currently, /proc/xxx/stack only output kernel stack call chain. We
> extend it to output user space call chain in hex format
>
> Signed-off-by: yanmin zhang <yanmin_zhang@linux.intel.com>
> Signed-off-by: xiaobing tu <xiaobing.tu@intel.com>
Ok, so I don't like it.. for one I really don't see the need for this,
secondly the implementation is crappy, thirdly the interface is poor.
> ---
> arch/x86/kernel/stacktrace.c | 55 ++++++++++++++++++++++++++++++++++++++++++
> fs/proc/base.c | 19 +++++++++++++-
> include/linux/stacktrace.h | 5 +++-
> 3 files changed, 77 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/stacktrace.c b/arch/x86/kernel/stacktrace.c index fdd0c64..d802f05 100644
> --- a/arch/x86/kernel/stacktrace.c
> +++ b/arch/x86/kernel/stacktrace.c
> @@ -7,6 +7,7 @@
> #include <linux/stacktrace.h>
> #include <linux/module.h>
> #include <linux/uaccess.h>
> +#include <linux/mm.h>
> #include <asm/stacktrace.h>
>
> static int save_stack_stack(void *data, char *name) @@ -144,3 +145,57 @@ void save_stack_trace_user(struct stack_trace *trace)
> trace->entries[trace->nr_entries++] = ULONG_MAX; }
>
> +static inline void __save_stack_trace_user_task(struct task_struct *task,
> + struct stack_trace *trace)
> +{
> + const struct pt_regs *regs = task_pt_regs(task);
> + const void __user *fp;
> + unsigned long addr;
> +
> + if (task != current && task->state == TASK_RUNNING && task->on_cpu) {
> + /* To trap into kernel at least once */
> + smp_send_reschedule(task_cpu(task));
> + }
This doesn't make any sense at all..
> +
> + fp = (const void __user *)regs->bp;
> + if (trace->nr_entries < trace->max_entries)
> + trace->entries[trace->nr_entries++] = regs->ip;
> +
> + while (trace->nr_entries < trace->max_entries) {
> + struct stack_frame_user frame;
> +
> + frame.next_fp = NULL;
> + frame.ret_addr = 0;
> +
> + addr = (unsigned long)fp;
> + if (!access_process_vm(task, addr, (void *)&frame,
> + sizeof(frame), 0))
> + break;
> + if ((unsigned long)fp < regs->sp)
> + break;
> + if (frame.ret_addr) {
> + trace->entries[trace->nr_entries++] =
> + frame.ret_addr;
> + }
> + if (fp == frame.next_fp)
> + break;
> + fp = frame.next_fp;
> + }
> +}
> +
> +void save_stack_trace_user_task(struct task_struct *task,
> + struct stack_trace *trace)
> +{
> + if (task == current || !task) {
> + save_stack_trace_user(trace);
> + return;
> + }
> +
> + if (task->mm)
> + __save_stack_trace_user_task(task, trace);
> +
> + if (trace->nr_entries < trace->max_entries)
> + trace->entries[trace->nr_entries++] = ULONG_MAX; }
> +EXPORT_SYMBOL_GPL(save_stack_trace_user_task);
There's already userspace stack walkers, don't reimplement them yet
again.
> diff --git a/fs/proc/base.c b/fs/proc/base.c index d4548dd..603e708 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -327,8 +327,25 @@ static int proc_pid_stack(struct seq_file *m, struct pid_namespace *ns,
> seq_printf(m, "[<%pK>] %pS\n",
> (void *)entries[i], (void *)entries[i]);
> }
> - unlock_trace(task);
> + } else
> + goto out;
> +
> + trace.nr_entries = 0;
> + trace.max_entries = MAX_STACK_TRACE_DEPTH;
> + trace.entries = entries;
> + trace.skip = 0;
> +
> + seq_printf(m, "userspace\n");
> +
> + save_stack_trace_user_task(task, &trace);
> +
> + for (i = 0; i < trace.nr_entries; i++) {
> + if (entries[i] != ULONG_MAX)
> + seq_printf(m, "%p\n", (void *)entries[i]);
> }
> + unlock_trace(task);
> +
> +out:
Writing out just the IPs means you have to have a stored snapshot
of /proc/$PID/maps around to make any sense of them. This seems a
relatively poor interface.
next prev parent reply other threads:[~2012-04-20 9:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-11 8:07 [RFC 1/2] kernel patch for dump user space stack tool Tu, Xiaobing
2012-04-17 4:43 ` Lin Ming
2012-04-17 14:38 ` Tu, Xiaobing
2012-04-20 9:44 ` Peter Zijlstra [this message]
2012-04-24 1:30 ` Yanmin Zhang
2012-04-24 10:10 ` Peter Zijlstra
2012-04-25 2:58 ` Yanmin Zhang
2012-04-24 10:11 ` Peter Zijlstra
2012-04-25 2:44 ` Yanmin Zhang
-- strict thread matches above, loose matches on Subject: below --
2012-04-17 14:37 Tu, Xiaobing
2012-04-19 3:50 ` Cong Wang
2012-04-19 5:17 ` Yanmin Zhang
2012-04-19 6:13 ` Cong Wang
2012-04-19 6:28 ` Yanmin Zhang
2012-04-20 9:38 ` Peter Zijlstra
2012-04-24 0:56 ` Yanmin Zhang
2012-04-20 9:54 ` Peter Zijlstra
2012-04-24 2:19 ` Yanmin Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1334915073.2463.36.camel@laptop \
--to=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=jiao.zuo@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--cc=xiaobing.tu@intel.com \
--cc=yanmin_zhang@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox