[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1335262248.28150.191.camel@twins>
Date: Tue, 24 Apr 2012 12:10:48 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Yanmin Zhang <yanmin_zhang@...ux.intel.com>
Cc: Cong Wang <xiyou.wangcong@...il.com>,
"Tu, Xiaobing" <xiaobing.tu@...el.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"mingo@...e.hu" <mingo@...e.hu>,
"rusty@...tcorp.com.au" <rusty@...tcorp.com.au>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"Zuo, Jiao" <jiao.zuo@...el.com>
Subject: Re: [RFC 1/2] kernel patch for dump user space stack tool
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists