[lkml]   [2000]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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.

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


[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
Please read the FAQ at

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