Messages in this thread | | | Date | Thu, 28 Sep 2000 22:53:05 +0200 | From | Andries Brouwer <> | Subject | Re: PIDs limited to 15 significant bits |
| |
On Wed, Sep 27, 2000 at 02:32:17PM +0100, Bernhard Bender wrote:
> looking at my process list after a week or so of uptime I discoverd that PIDs > seem to wrap around at 32767 (aka. 2^15 - 1).
Yes.
> I find this "feature" annoying, since I like to view my process list sorted > by PID, which gives a nice overview about recently started processes vs. > age-old daemons. > > So, I would like to ask if someone could please explain the reason for this. > If there is no compelling reason I would like to propose to remove this > limit. I recall this was not present in 2.2.x
You recall incorrectly.
The code is old. There is very little reason for it, and we could change today. In fact I think I once submitted the corresponding patch. My machines regularly see 6- or 7-digit PIDs.
There are two very minor points:
(i) If you are in the habit of tar'ing up /proc, and moreover the tar you use considers files with the same device and inode to be identical, then your tarfiles may become smaller after the patch
-#define fake_ino(pid,ino) (((pid)<<16)|(ino)) +#define fake_ino(pid,ino) (((1)<<16)|(ino))
in fs/proc/base.c.
(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) struct shmid_ds. Nothing compiled today uses this, and almost nothing uses it at all, but this nevertheless means that one needs an option CONFIG_15BIT_PID (default=N) for backward binary compatibility.
Andries
[The patch is available. There are a few security advantages. Also, it makes a fork a just measurable fraction of a percent faster.]
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |