> I.e, if PID_MAX is 30000, can a PID > 30000 ever be allocated?
> If so, then this is not the correct behaviour IMHO.

I'll turn it the other way around.
If you cannot allocate a PID below PID_MAX should you:

1) loop forever with interrupts disabled hoping one will appear [1]
2) error the fork()
3) allocate a number above PID_MAX

> I can think of specific cases where a user does not want a new PID to
> exceed PID_MAX under any circumstance.  E.g, for compatiblity with
> certain systems with 16 bit PIDs (PID_MAX =~ 32767), or where PIDs
> aren't to exceed 5 digits when printed (PID_MAX == 99999).

That can be guaranteed by ensuring that maxproc is less than ~4777 [2].
(I'd have to check the actual value)

Note that because the table is sized 2^n it is hard to stop pids
between 30001 and 32767 being allocated when more that 16383 pids
are required.

> Also, procfs checks that the requested pid doesn't exceed PID_MAX,
> so if your code doesn't enforce this limitation, you won't be able to
> access those via procfs. ("oops!")

That is a silly restriction in procfs, I thought I'd killed it.

	David

[1] IIRC the old code could easily do that.
[2] Each process can require unique pid, pgid and sid, it isn't
    16384/3 because about 2000 pids are kept idle to help detect
    stale pud values.

-- 
David Laight: david@l8s.co.uk