lkml.org 
[lkml]   [2000]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux 2.3.39 has 32bit uid. What about 32bit pid?
    Petr Vandrovec:

    > but some (two) of these structures include also __kernel_pid_t.
    > So I'd like to ask, whether we are going to 32bit pid_t in 2.3.

    Alan:
    > Probably not. Let me ask a related question - are you going to miss 2 bytes of
    > padding in case ? I'd use 32bits in case.


    I think we should change __kernel_pid_t now that we are changing __kernel_uid_t.

    a) It is easy - easier than the change to larger uid.
    Roughly speaking the only change is in the ipc structs.
    (The other part of the change is in /proc.)

    b) The reuse of pids causes security problems.

    c) 32000 processes is not enough.

    d) There is a speed advantage:
    Right now when a process is spawned we have to find a pid for it,
    and with a few thousand threads a significant part of the 32000
    pids allowed today will be in use, so that often get_pid() will
    have to walk the entire task list. If we are sure that a pid is
    never reused, then

    get_pid() {
    return ++last_pid;
    }

    suffices. Even when reuse occurs, the current get_pid() will
    be much more efficient when a larger pid-space is available.

    (On the other hand, if we do not enlarge the pid_t size, then
    a bitmap with pids_in_use would make get_pid() much faster.)



    In fact, I like high uptimes, and a system in which the same pid is never
    used again. But this means that 32 bits may not be enough. That again
    means that I would like to see padding in places like

    struct msqid64_ds {
    ...
    __kernel_pid_t msg_lspid; /* pid of last msgsnd */
    __kernel_pid_t msg_lrpid; /* last receive pid */
    unsigned long __unused4;
    unsigned long __unused5;
    };

    that is, I would prefer to see there

    __kernel_pid_t msg_lspid; /* pid of last msgsnd */
    unsigned long __unused4;
    __kernel_pid_t msg_lrpid; /* last receive pid */
    unsigned long __unused5;

    so that it will be easier to go to 64-bit pids twelve years from now.

    Andries


    [I may still have some usable patch fragments for getpid and family.]


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:2.223 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site