(1) We cannot move to 31/32 bit PIDs for 2.2 - 2.3 maybe, but not 2.2.
(2) If we are to allow random PIDs, then on a moderately busy system, PID
re-use (within a short amount of time) is going to occur, and a highly
loaded really busy systems its going to occur fairly often....
(3) Any user-space code this breaks I guess can be considered broken and
will probably have to be fixed....
Now this probably includes Apache - but since this situation can occur
under OpenBSD which presumably apache runs under, a work around has to
be found anyhow.
And programs that generate message IDs, etc (and Dean Gaudlet pointed)
out by doing "time() concat getpid()" will also have to be fixed. I'm
not sure how many things will be affected by this, but its broken
anyhow.
(Perhaps, and its probably a bit far-fetched, but as the net grows, the
odds on a non-deliberate collision are increasing all the time,
especially if the algorithm only uses the hostname and not the fqdn).
That said, why when PIDs wrap do they renumber starting from 300? This only
makes a small amount of sense in that daemons, etc. when they start up will
have PIDs<300 - but is that really of any use?
Also... what is a suitable way to seed the PRNG?
Normally I would say get entropy for the /dev/random driver (intercept
bits?, we only need a few bits every now and then and this is perhaps more
important), but for a cleanly booted system there isn't much to go around...
(and the Debian system where saving entropy from /dev/random on shutdown and
restoring on power-up is horrendous IMO and should be discontinued. Consider
what could occur by poisoning this data then having someone generate a PGP
key or something).
Thoughts? Flames?
-Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu