[lkml]   [2000]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PIDs limited to 15 significant bits
Andries Brouwer writes:
> On Wed, Sep 27, 2000 at 02:32:17PM +0100, Bernhard Bender wrote:

> The code is old.
> There is very little reason for it, and we could change today.

Some userspace software uses "short" for PIDs. Bash did this.

> In fact I think I once submitted the corresponding patch.
> My machines regularly see 6- or 7-digit PIDs.

Oh, the horror!

Consider, do you like to type "kill 1234567890" more than
a simple "kill 1234"?

What do you think of "ps -efj" on a standard 80x24 screen?

The limit should be 9999 by default, because this keeps the
numbers conveniently small. If you really need more processes
than that, going to 65000 or 99999 might be reasonable.

> (ii) There is also a rather obscure place in SYSV IPC where a 16-bit pid_t
> is used for the fields msg_lspid and msg_lrpid of the (obsolete)
> struct msqid_ds and the fields shm_cpid and shm_lpid of the (obsolete)

Gee, another reason to keep the limit low.

> [The patch is available. There are a few security advantages.

There should not be any significant security advantages.
One can easily wrap/predict in a 31-bit space.
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 12:38    [W:0.071 / U:1.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site