[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100923221139.GI23839@count0.beaverton.ibm.com>
Date: Thu, 23 Sep 2010 15:11:39 -0700
From: Matt Helsley <matthltc@...ibm.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: holzheu@...ux.vnet.ibm.com, Shailabh Nagar <nagar1234@...ibm.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Venkatesh Pallipadi <venki@...gle.com>,
John stultz <johnstul@...ibm.com>,
containers@...ts.linux-foundation.org, linux-s390@...r.kernel.org,
Balbir Singh <balbir@...ux.vnet.ibm.com>,
Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Suresh Siddha <suresh.b.siddha@...el.com>
Subject: Re: [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@...ux.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists