From: Ralf Baechle <[email protected]>
I'd actually like to see a 64-bit pid_t.
First of all, I've already once being bitten
by a bug caused by a re-used PID...
Yes, eventually we'll have to.
But a 32-bit pid_t is not so bad:
With a hundred new processes spawned every second
a 32-bit pid_t will wrap only after about 500 days.
(Of course the bad part is that a wrap will still occur;
as you already said, code is much simplified if we are
sure that no pid will ever be reused.)
The present situation however is much worse:
the pid_t wraps from 32767 to 300 (kernel/fork.c).
On the one hand this means that one cannot have more than 2^15
processes. On the other hand this causes some security problems.
Changing the size of pid_t to 64-bit is a major operation.
Lots of system calls have pid_t arguments or return pid_t
results. And pid_t occurs many other places. For example,
a struct flock has a pid_t field.
Moreover, glibc doesnt have machinery in place to change
the size of a pid_t. So, if I am not mistaken, this would
require a new major number for the library.
But if pid_t is 32-bit, then why does the kernel only use 15 bits?
We have
#define PID_MAX 0x8000
in <linux/tasks.h>, and at first sight not much goes wrong
if we pick some larger number for PID_MAX, like 0x7fffffff.
(There are some comparisons around, so for simplicity we should
keep PID_MAX positive.)
Hmm - but then what is it that goes wrong?
In include/asm-i386/posix_types.h we have
typedef unsigned short __kernel_ipc_pid_t;
(and the same for m68k, ppc, sparc, arm).
This is the type of the fields msg_lspid, msg_lrpid, shm_cpid, shm_lpid
of struct msqid_ds and shmid_ds. Such structures are returned by
the system calls msgctl() and shmctl().
So, using larger pid's gives some trouble with SYSV IPC.
(And again glibc is unable to cope with changes, although
the trouble is minor in this case.)
Conclusion:
- a 64-bit pid_t is most convenient for the kernel, but
gives trouble with libc.
- a 32-bit pid_t is what we have today, but we use only
15 bits because of SYSV IPC (or perhaps other reasons
I am unaware of).
Andries
On Sun, Jun 13, 1999 at 08:47:08PM +0200, [email protected] wrote:
> #define PID_MAX 0x8000
> in <linux/tasks.h>, and at first sight not much goes wrong
> if we pick some larger number for PID_MAX, like 0x7fffffff.
> (There are some comparisons around, so for simplicity we should
> keep PID_MAX positive.)
Also, a negative pid_t is used to represent the process group in some
calls, notably the SIOCSPGRP and SIOCGPGRP ioctls.
--
Matthew Wilcox <[email protected]>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson
On Sun, Jun 13, 1999 at 08:47:08PM +0200, [email protected] wrote:
> Changing the size of pid_t to 64-bit is a major operation.
> Lots of system calls have pid_t arguments or return pid_t
> results. And pid_t occurs many other places. For example,
> a struct flock has a pid_t field.
> Moreover, glibc doesnt have machinery in place to change
> the size of a pid_t. So, if I am not mistaken, this would
> require a new major number for the library.
>
> But if pid_t is 32-bit, then why does the kernel only use 15 bits?
> We have
> #define PID_MAX 0x8000
> in <linux/tasks.h>, and at first sight not much goes wrong
> if we pick some larger number for PID_MAX, like 0x7fffffff.
> (There are some comparisons around, so for simplicity we should
> keep PID_MAX positive.)
>
>
> Hmm - but then what is it that goes wrong?
> In include/asm-i386/posix_types.h we have
> typedef unsigned short __kernel_ipc_pid_t;
> (and the same for m68k, ppc, sparc, arm).
Alpha, MIPS and Sparc64 on the other side do use a 32-bit *pid_t and
are limited by the current implementation to effectivly 15 bit.
> This is the type of the fields msg_lspid, msg_lrpid, shm_cpid, shm_lpid
> of struct msqid_ds and shmid_ds. Such structures are returned by
> the system calls msgctl() and shmctl().
> So, using larger pid's gives some trouble with SYSV IPC.
> (And again glibc is unable to cope with changes, although
> the trouble is minor in this case.)
>
>
> Conclusion:
> - a 64-bit pid_t is most convenient for the kernel, but
> gives trouble with libc.
Note that I have a chance for a fresh start for MIPS64. Binary
compatibility is therefore not an issue. Furthermore it's a 64-bit
architecture, so the code size itself will not increase.
The biggest problem will probably be code which does things like
int pid;
pid = fork();
Finding them all is going to be quite a nasty problem. Making the kernel
/ libc reject pids that are signed / unsigned expanded 32-bit numbers
except init's pid will support that, hopefully.
> - a 32-bit pid_t is what we have today, but we use only
> 15 bits because of SYSV IPC (or perhaps other reasons
> I am unaware of).
Pids in the range of [0 ... 32000[ are pretty much tradition among
unices since about the time UNIX was born. Linux does things slightly
more efficient by using the entire range of [0 ... 32768].
Ralf
Hi!
> I'd actually like to see a 64-bit pid_t.
> First of all, I've already once being bitten
> by a bug caused by a re-used PID...
>
> Yes, eventually we'll have to.
> But a 32-bit pid_t is not so bad:
> With a hundred new processes spawned every second
> a 32-bit pid_t will wrap only after about 500 days.
Everyone should assume PID's are being reused! If you have buggy apps
which assume pid's not to be reused, then just watch your proc and
reboot when you are coming to 2G-th process ;-). (Ok, there's one bug
in kernel w.r.t. pid wrapparound - in console and it allows console
user to send arbitrary signals to newly created processes.)
What is bad is that clusters pretty much need 32bit pids...
> Conclusion:
> - a 64-bit pid_t is most convenient for the kernel, but
> gives trouble with libc.
> - a 32-bit pid_t is what we have today, but we use only
> 15 bits because of SYSV IPC (or perhaps other reasons
> I am unaware of).
And becuase /proc internals. But please please go and change it.
Pavel
--
I'm really [email protected]. Look at http://195.113.31.123/~pavel. Pavel
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
Some Unices (AIX?) use random PID allocation to make PID
prediction more difficult. Is this perceived to be worth
it, or is it a non-issue?
miket
On Sun, Jun 13, 1999 at 09:48:10PM +0200, Pavel Machek wrote:
>
> >
> > Yes, eventually we'll have to.
> > But a 32-bit pid_t is not so bad:
> > With a hundred new processes spawned every second
> > a 32-bit pid_t will wrap only after about 500 days.
>
> Everyone should assume PID's are being reused! If you have buggy apps
> which assume pid's not to be reused, then just watch your proc and
> reboot when you are coming to 2G-th process ;-). (Ok, there's one bug
> in kernel w.r.t. pid wrapparound - in console and it allows console
> user to send arbitrary signals to newly created processes.)
>
> What is bad is that clusters pretty much need 32bit pids...
>
> > Conclusion:
> > - a 64-bit pid_t is most convenient for the kernel, but
> > gives trouble with libc.
> > - a 32-bit pid_t is what we have today, but we use only
> > 15 bits because of SYSV IPC (or perhaps other reasons
> > I am unaware of).
>
> And becuase /proc internals. But please please go and change it.
>
> Pavel