Re: pid_t range question

[ebiederm@xmission.com (Eric W. Biederman)]

"linux-os \(Dick Johnson\)" <linux-os@analogic.com> writes:

> On Linux, type pid_t is defined as an int if you look
> through all the intermediate definitions such as S32_T,
> etc. However, it wraps at 32767, the next value being 300.
>
> Does anybody know why it doesn't go to 0x7fffffff and
> then wrap to the first unused pid value? I know the
> code "reserves" the first 300 pids. That's not the
> question. I wonder why. Also I see the code setting
> the upper limit as well. I want to know why it is
> set within the range of a short and is not allowed
> to use the full range of an int. Nothing I see in
> the kernel, related to the pid, ever uses a short
> and no 'C' runtime interface limits this either!

I have a vague memory about some old kernel interfaces
where pid was a short.  That said 32768 is also the number
of bits in a page so it is a very good number for the bitmap
allocator we currently have.

I know for certain that proc assumes it can fit pid in
the upper bits of an ino_t taking the low 16bits for itself
so that may the entire reason for the limit.

> Also, attempts to change /proc/sys/kernel/pid_max fail
> if I attempt to increase it, but I can decrease it
> to where I don't have enough pids available to fork()
> the next command! Is this the correct behavior?

You can increase pid_max if you have a 64bit kernel.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/