All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	containers@lists.osdl.org, fweisbec@gmail.com,
	Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
	srostedt@redhat.com, Eric Biederman <ebiederm@xmission.com>,
	Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
	"Serge E. Hallyn" <serue@us.ibm.com>
Subject: Re: [PATCH 1/3] ftrace: add function tracing to single thread
Date: Tue, 25 Nov 2008 16:53:59 -0800	[thread overview]
Message-ID: <1227660839.12109.52.camel@nimitz> (raw)
In-Reply-To: <alpine.DEB.1.10.0811251909320.26424@gandalf.stny.rr.com>

On Tue, 2008-11-25 at 19:11 -0500, Steven Rostedt wrote:
> > > > Steven Rostedt <rostedt@goodmis.org> wrote:
> > > > 
> > > > > This patch adds the ability to function trace a single thread.
> > > > > The file:
> > > > > 
> > > > >   /debugfs/tracing/set_ftrace_pid
> > > > > 
> > > > > contains the pid to trace.
> > > > 
> > > > What happens if the same pid exists in two or more pid namespaces?
> > > 
> > > I think we had this discussion before.
> > 
> > Oh.  What did we end up concluding?
> > 
> > > It tests current->pid, would that 
> > > be different among the name spaces?
> > 
> > I think those are non-unique.  containers@lists.osdl.org would have
> > better ideas..
> 
> Added list in CC.
> 
> I think the end result was, if this file can only be changed by root, then 
> we do not need to worry about namespaces. This file is a privileged file 
> that can only be modified by root.
> 
> If someday we decide to let non admin users touch this file, then we would
> need to care about this.  This file may actually be modified in the future 
> by users, so this may become an issue.

This really has very little to do with root vs non-root users.  In fact,
we're working towards having cases where we have many "root" users, even
those inside namespaces.  It is also quite possible for a normal root
user to fork into a new pid namespace.  In that case, root simply won't
be able to use this feature because something like:
	
	echo $$ /debugfs/tracing/set_ftrace_pid
	
just won't work.  Let's look at a bit of the code.

+static void ftrace_pid_func(unsigned long ip, unsigned long parent_ip)
+{
+       if (current->pid != ftrace_pid_trace)
+               return;
+
+       ftrace_pid_function(ip, parent_ip);
+}

One thing this doesn't deal with is pid wraparound.  Does that matter?

If you want to fix this a bit, instead of saving off the pid_t in
ftrace_pid_trace, you should save a 'struct pid'.  You can get the
'struct pid' for a particular task by doing a find_get_pid(pid_t).  You
can then compare that pid_t to current by doing a
pid_task(struct_pid_that_i_saved, PIDTYPE_PID).  That will also protect
against pid wraparound.

The find_get_pid() is handy because it will do the pid_t lookup in the
context of the current task's pid namespace, which is what you want, I
think.

-- Dave

  reply	other threads:[~2008-11-26  0:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-25 22:34 [PATCH 0/3] ftrace: new features Steven Rostedt
2008-11-25 22:34 ` [PATCH 1/3] ftrace: add function tracing to single thread Steven Rostedt
2008-11-25 22:42   ` Andrew Morton
2008-11-25 23:01     ` Steven Rostedt
2008-11-25 23:31       ` Andrew Morton
2008-11-26  0:11         ` Steven Rostedt
2008-11-26  0:53           ` Dave Hansen [this message]
2008-11-26  1:01             ` Steven Rostedt
2008-11-26  4:50               ` Eric W. Biederman
2008-11-26  5:01                 ` Steven Rostedt
2008-11-26  6:23                   ` Eric W. Biederman
2008-11-26  6:32                     ` Ingo Molnar
2008-11-26  7:02                       ` Eric W. Biederman
2008-11-26  7:18                         ` Ingo Molnar
2008-11-26  8:48                           ` Eric W. Biederman
2008-11-26  5:20               ` Eric W. Biederman
2008-11-26 16:36                 ` Steven Rostedt
2008-11-26  0:02   ` Frédéric Weisbecker
2008-11-26  0:16     ` Steven Rostedt
2008-11-25 22:34 ` [PATCH 2/3] ftrace: use code patching for ftrace return tracer Steven Rostedt
2008-11-26  0:13   ` Frédéric Weisbecker
2008-11-26  0:23   ` Steven Rostedt
2008-11-25 22:34 ` [PATCH 3/3] ftrace: let function tracing and function return run together Steven Rostedt

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=1227660839.12109.52.camel@nimitz \
    --to=dave@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=containers@lists.osdl.org \
    --cc=ebiederm@xmission.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=serue@us.ibm.com \
    --cc=srostedt@redhat.com \
    --cc=sukadev@linux.vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.