Re: /proc/sys/kernel/pid_max issues

[Albert Cahalan <albert@users.sf.net>]

On Mon, 2004-09-13 at 10:24, William Lee Irwin III wrote:
> On Mon, 2004-09-13 at 03:57, Ingo Molnar wrote:
> >> this is a pretty sweeping assertion. Would you
> >> care to mention a few examples of such hazards?
> 
> On Mon, Sep 13, 2004 at 09:54:09AM -0400, Albert Cahalan wrote:
> > kill(12345,9)
> > setpriority(PRIO_PROCESS,12345,-20)
> > sched_setscheduler(12345, SCHED_FIFO, &sp)
> > Prior to the call being handled, the process may
> > die and be replaced. Some random innocent process,
> > or a not-so-innocent one, will get acted upon by
> > mistake. This is broken and dangerous.
> > Well, it's in the UNIX standard. The best one can
> > do is to make the race window hard to hit, with LRU.
> 
> How do you propose to queue pid's? This is space constrained. I don't
> believe it's feasible and/or desirable to attempt this, as there are
> 4 million objects to track independent of machine size.

As we've seen elsewhere in this thread, things break
when you go above 0xffff anyway. So 128 KiB of RAM
should do the job. With a 4-digit PID, 20000 bytes
would be enough.

Supposing you fix rwsem counts and /proc inodes and so on,
a large machine could handle 4 million objects easily.
A small machine has far, far, less need to support that.

> The general
> tactic of cyclic order allocation is oriented toward making this rare
> and/or hard to trigger by having a reuse period long enough that what
> processes there are after a pid wrap are likely to have near-indefinite
> lifetimes. i.e. it's the closest feasible approximation of LRU. If you
> truly want/need reuse to be gone, 64-bit+ pid's are likely best.

That's too unwieldy for the users, it breaks glibc,
and you'll still hit the problems after wrap-around.
Besides, Linus vetoed this a year or two ago.

Reducing the dangers of a small PID space allows for
just the opposite size change, which is much nicer for
the users.