lkml.org 
[lkml]   [2004]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: /proc/sys/kernel/pid_max issues
    From
    Date
    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.


    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 14:06    [W:0.040 / U:3.692 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site