Messages in this thread | | | Date | Sun, 13 Aug 2006 16:08:20 -0400 | From | "Albert Cahalan" <> | Subject | Re: [RFC] ps command race fix |
| |
On 8/13/06, Eric W. Biederman <ebiederm@xmission.com> wrote: > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> writes:
> > /* > > * A maximum of 4 million PIDs should be enough for a while. > > * [NOTE: PID/TIDs are limited to 2^29 ~= 500+ million, see futex.h.] > > */ > > #define PID_MAX_LIMIT (CONFIG_BASE_SMALL ? PAGE_SIZE * 8 : \ > > (sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT)) > > > > ...we have to manage 4 millions tids.
BTW, it looks like powerpc runs out of MMU contexts if there are more than 32768 processes. Badness happens.
> The basic posix/susv guarantee is that in readdir if a directory > entry is neither deleted nor added between opendir and closedir of the > directory you should see the directory entry. I could not > quite tell what the rules were with regards seekdir.
Never minding the bare minimum, I think the user-visible offset should be the PID plus some constant for all PIDs. (sadly, the constant can't be 0 because of ".." and init)
> There are also other reasons to changing to a pid base traversal > of /proc. It allows us to display information on process groups, > and sessions whose original leader has died.
Huh?
> If namespaces get > assigned a pid traversal by pid looks like a good way to display > namespaces that are not used by any process but are still alive. > Albert does that sound like a sane extension?
You mean /proc/42 could be non-process data? That will surely break lots and lots of things.
In general, process namespaces are useful for:
1. silly marketing (see Sun and FreeBSD)
2. the very obscure case of "root" account providers who are too clueless to use SE Linux or Xen
I don't think either case justifies the complexity. I am not looking forward to the demands that I support this mess in procps. I suspect I am not alone; soon people will be asking for support in pstools, gdb, fuser, killall... until every app which interacts with other processes will need hacks.
If the cost were only an #ifdef in the kernel, there would be no problem. Unfortunately, this is quite a hack in the kernel and it has far-reaching consequenses in user space. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |