Messages in this thread | | | Date | Thu, 13 Jan 2000 14:59:45 +0100 (MET) | From | Andries.Brouwer@cwi ... | Subject | Re: 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/
| |