Messages in this thread | | | Date | Mon, 13 Sep 2004 07:24:37 -0700 | From | William Lee Irwin III <> | Subject | Re: /proc/sys/kernel/pid_max issues |
| |
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. 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.
-- wli - 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/
| |