public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yanmin Zhang <yanmin_zhang@linux.intel.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Cong Wang <xiyou.wangcong@gmail.com>,
	"Tu, Xiaobing" <xiaobing.tu@intel.com>,
	"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>,
	"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: Wed, 25 Apr 2012 10:58:17 +0800	[thread overview]
Message-ID: <1335322697.14538.116.camel@ymzhang.sh.intel.com> (raw)
In-Reply-To: <1335262248.28150.191.camel@twins>

On Tue, 2012-04-24 at 12:10 +0200, Peter Zijlstra wrote:
> On Tue, 2012-04-24 at 09:30 +0800, Yanmin Zhang wrote:
> > > > +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..
> > ptrace could put the task to a either STOPPED or TRACED state.
> > But it's time-consuming. 
> 
> Yeah, but what is the above meant to achieve? it doesn't actually stop
> the task or anything, it will just trap the remote cpu, by the time you
> do your stack walk below the cpu might be running another task entirely
> or you're walking a life stack with all the 'fun' issues that'll bring.
When we access the user space stack, it's based on _task_, not cpu.

The IPI is to make sure the task could trap into kernel at least once,
so we could get its regs->bp. If the task is running on another cpu
for a long time, the regs->bp might be too old. I am also a little worried
about that if the task restores to user space to run quickly after the IPI,
regs->bp might be ruined. If it's true, we might get bad data, or couldn't
get useful data.

See below codes.
+       const struct pt_regs *regs = task_pt_regs(task);
Above pt_regs is task's, not current's.

+       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));
+       }
+
+       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))
Above line would access the task's user space stack.

We implemented the tool based on real requirement and it's not perfect. So
we need your expertise help.

Thanks for the comments.

Yanmin



  reply	other threads:[~2012-04-25  2:57 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
2012-04-24  1:30   ` Yanmin Zhang
2012-04-24 10:10     ` Peter Zijlstra
2012-04-25  2:58       ` Yanmin Zhang [this message]
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=1335322697.14538.116.camel@ymzhang.sh.intel.com \
    --to=yanmin_zhang@linux.intel.com \
    --cc=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=xiyou.wangcong@gmail.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