lkml.org 
[lkml]   [2010]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 00/10] taskstats: Enhancements for precise accounting
On Thu, Sep 23, 2010 at 01:11:36PM -0700, Andrew Morton wrote:
> On Thu, 23 Sep 2010 15:48:01 +0200
> Michael Holzheu <holzheu@linux.vnet.ibm.com> wrote:
>
> > Currently tools like "top" gather the task information by reading procfs
> > files. This has several disadvantages:
> >

<snip>

> > 3. A new tool "ptop" (precise top) that uses the libraries
>
> Talk to me about namespaces, please. A lot of the new code involves
> PIDs, but PIDs are not system-wide unique. A PID is relative to a PID
> namespace. Does everything Just Work? When userspace sends a PID to
> the kernel, that PID is assumed to be within the sending process's PID
> namespace? If so, then please spell it all out in the changelogs. If
> not then that is a problem!

Good point.

The pid ought to be valid in the _receiving_ task's pid namespace. That
can be difficult or impossible if we're talking about netlink broadcasts.
In this regard process events connector is an example of what not to do.

> If I can only observe processes in my PID namespace then is that a
> problem? Should I be allowed to observe another PID namespace's
> processes? I assume so, because I might be root. If so, how is that
> to be done?

I don't think even "root" can see/use pids outside its namespace (without
Eric's setns patches). If you want to see all the tasks then rely on root
being able to do stuff in the initial pid namespace. If you really want
to use/know pids in the child pid namespaces then setns is also a
nice solution.

Cheers,
-Matt Helsley


\
 
 \ /
  Last update: 2010-09-27 20:09    [W:0.548 / U:0.256 seconds]
©2003-2014 Jasper Spaans. Advertise on this site