From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932560AbcFCQlf (ORCPT ); Fri, 3 Jun 2016 12:41:35 -0400 Received: from mail-pf0-f171.google.com ([209.85.192.171]:36798 "EHLO mail-pf0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932259AbcFCQle (ORCPT ); Fri, 3 Jun 2016 12:41:34 -0400 Date: Fri, 3 Jun 2016 09:41:29 -0700 From: Omar Sandoval To: Masami Hiramatsu Cc: Namhyung Kim , Steven Rostedt , Ingo Molnar , LKML , kernel-team@fb.com, Omar Sandoval Subject: Re: [PATCH] tracing: expose current->comm to kprobe events Message-ID: <20160603164129.GA12041@vader> References: <20160603175943.934b96be3a332bb80fdc7c19@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160603175943.934b96be3a332bb80fdc7c19@kernel.org> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 03, 2016 at 05:59:43PM +0900, Masami Hiramatsu wrote: > On Fri, 3 Jun 2016 00:40:02 +0900 > Namhyung Kim wrote: > > > Hello, > > > > On Wed, Jun 1, 2016 at 3:17 PM, Omar Sandoval wrote: > > > From: Omar Sandoval > > > > > > 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