Re: [PATCH] tracing: expose current->comm to kprobe events

[Omar Sandoval <osandov@osandov.com>]

On Fri, Jun 03, 2016 at 05:59:43PM +0900, Masami Hiramatsu wrote:
> On Fri, 3 Jun 2016 00:40:02 +0900
> Namhyung Kim <namhyung@gmail.com> wrote:
> 
> > Hello,
> > 
> > On Wed, Jun 1, 2016 at 3:17 PM, Omar Sandoval <osandov@osandov.com> wrote:
> > > From: Omar Sandoval <osandov@fb.com>
> > >
> > > ftrace is very quick to give up on saving the task command line (see
> > > `trace_save_cmdline()`). The workaround for events which really care
> > > about the command line is to explicitly assign it as part of the entry.
> > > However, this doesn't work for kprobe events, as there's no
> > > straightforward way to get access to current->comm. Add a kprobe event
> > > variable $comm which provides exactly that.
> 
> Hmm, would you already tried to trace task/task_newtask and task/task_rename
> events? which also gives you task's comm.
> Of course there are no way to get running task's comm...

Right, I was trying to figure out what task was hitting a specific code
path, so I don't think that would work.

> Anyway, I also think more generic idea, e.g. enable to get "current" address.
> With the "current" address, we can do similar thing (by using perf-probe)

Yeah, that would also be useful in general. I think having this is still
convenient for quick debugging.

> The code looks good to me. As Namhyung said, it should support uprobes
> too.

Yesterday I sent out v2 which also supports uprobes, let me know if you
didn't receive it.

> BTW, now I'm considering integrate kprobes and uprobes ftrace interface.
> It is easy to classify given event definition is for kprobes or uprobes.
> So, we don't need to have 2 different interfaces for it.
> 
> Thank you,

Thanks for taking a look.

-- 
Omar