linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Cc: Nikolay Borisov <kernel@kyup.com>,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	mingo@redhat.com, paulus@samba.org, acme@kernel.org,
	hbathini@linux.vnet.ibm.com, ananth@in.ibm.com
Subject: Re: [RFC PATCH 2/2] perf: Filter events based on perf-namespace
Date: Tue, 12 Jul 2016 21:34:18 +0530	[thread overview]
Message-ID: <57851502.2070909@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160712142753.GT30909@twins.programming.kicks-ass.net>



On Tuesday 12 July 2016 07:57 PM, Peter Zijlstra wrote:
> On Tue, Jul 12, 2016 at 08:55:17AM -0500, Eric W. Biederman wrote:
> 
>> I completely misread the description of this, or I would have something
>> earlier.  For some reason I thought he was talking about the perf
>> controller.
>>
>> As I recall the tricky part of this was to have tracing that was safe
>> and usable inside of a container.  If you can align a per cgroup with
>> your container that is probably sufficient for the select of processes.
>>

Aligning a cgroup with the container is sufficient if containers are
created with PID namespace. The first prototype was based on that.

However, not sure if it is fair to assume that the containers are
created with PID namespace and the processes inside the container are
grouped into a cgroup, as containers can be created without PID
namespace. In fact it was mentioned in LPC container micro-conference
that some containers are created without PID namespace as they need to
access host PIDs.

With the recent introduction of cgroup namespace, I think we can even
take out the requirement that container should be created with PID
namespace to enable safe tracing inside of a container. We are currently
evaluating that.


>> At the same time there is a real desire to have identifiers like pids
>> translated into the appropriate form for inside of the container.
>> Without that translation they are meaningless inside a container.
>> Further it is necessary to be certain the trancing that is used is is
>> safe for unprivileged users.

pid is already translated inside a container as mentioned below.

>>
>> I don't think I ever suggested or approved of the concept of a perf
>> namespace and that sounds a bit dubious to me.

Yes true this was not suggested during the discussion.

As the kernel does not have the concept of a container, we thought
introduction of perf-namespace could isolate events inside a container,
analogous to other namespaces.

> 
> So perf uses the pid-namespace of the event-creator to report PID/TID
> numbers in.
> 
> So sys_perf_event_open() -> perf_event_alloc() does
> get_pid_ns(task_active_pid_ns(current)) to set event->ns and then we do:
> task_{tgid,pid}_nr_ns(p, event->ns) to report the PID/TID resp., see
> perf_event_{pid,tid}().
> 

-- 
Regards,
Aravinda

  reply	other threads:[~2016-07-12 16:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-14 16:49 [RFC PATCH 0/2] perf: Container-aware tracing support Aravinda Prasad
2016-06-14 16:49 ` [RFC PATCH 1/2] perf/namespaces: Add a new namespace for isolated tracing Aravinda Prasad
2016-06-14 16:49 ` [RFC PATCH 2/2] perf: Filter events based on perf-namespace Aravinda Prasad
2016-06-27 15:50   ` Peter Zijlstra
2016-06-28 11:39     ` Aravinda Prasad
2016-07-12  9:26     ` Aravinda Prasad
2016-07-12 11:47       ` Peter Zijlstra
2016-07-12 12:41         ` Nikolay Borisov
2016-07-12 13:04           ` Peter Zijlstra
2016-07-12 13:55             ` Eric W. Biederman
2016-07-12 14:27               ` Peter Zijlstra
2016-07-12 16:04                 ` Aravinda Prasad [this message]
2016-07-12 16:19             ` Aravinda Prasad

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=57851502.2070909@linux.vnet.ibm.com \
    --to=aravinda@linux.vnet.ibm.com \
    --cc=acme@kernel.org \
    --cc=ananth@in.ibm.com \
    --cc=ebiederm@xmission.com \
    --cc=hbathini@linux.vnet.ibm.com \
    --cc=kernel@kyup.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).