Re: [RFC] ps command race fix

["Albert Cahalan" <acahalan@gmail.com>]

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/