Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1413357
| From | Omar Sandoval <osandov@osandov.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] tracing: expose current->comm to kprobe events |
| Date | 2016-06-03 18:50 +0200 |
| Message-ID | <rG0si-5FK-13@gated-at.bofh.it> (permalink) |
| References | <rF7Fv-4MU-1@gated-at.bofh.it> <rFD2G-7GN-21@gated-at.bofh.it> <rFTh8-1eC-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH] tracing: expose current->comm to kprobe events Omar Sandoval <osandov@osandov.com> - 2016-06-01 08:20 +0200
Re: [PATCH] tracing: expose current->comm to kprobe events Namhyung Kim <namhyung@gmail.com> - 2016-06-02 17:50 +0200
Re: [PATCH] tracing: expose current->comm to kprobe events Omar Sandoval <osandov@osandov.com> - 2016-06-02 20:30 +0200
Re: [PATCH] tracing: expose current->comm to kprobe events Masami Hiramatsu <mhiramat@kernel.org> - 2016-06-03 11:10 +0200
Re: [PATCH] tracing: expose current->comm to kprobe events Omar Sandoval <osandov@osandov.com> - 2016-06-03 18:50 +0200
csiph-web