---------- Forwarded message ---------- From: David CARLIER <[email protected]> Date: 18 December 2014 at 19:24 Subject: Re: pid max => exposure to userland To: Martin Natano <[email protected]>
Hi and thanks. On 18 December 2014 at 19:04, Martin Natano <[email protected]> wrote: > > Hello David, > > > Might be useful, for example, with ps ... parse_pid => strtonum might > > use pid_max as legit upper limit, ... top ... etc etc ... > Using pid_max to validate if a given number is a valid pid would yield > false negatives; there might be a process with a higher pid still > running _after_ pid_max has been set to a lower value via sysctl. > > > > diff --git a/sys/sys/proc.h b/sys/sys/proc.h > > index 335bc14..7192dad 100644 > > --- a/sys/sys/proc.h > > +++ b/sys/sys/proc.h > > @@ -407,6 +407,12 @@ struct uidinfo *uid_find(uid_t); > > #define PID_MAX 32766 > > #define NO_PID (PID_MAX+1) > > > > +/* > > + * Boundaries of sysctl possible values for pid_max > > + */ > > +#define PID_SYSCTL_LW 1024 > I think this value is far to low. Even with just a bunch of processes > you will have pid collisions in allocpid(), causing forking to take > longer. Also with the pid space getting smaller you make the pids > essentialy guessable, which counteracts the idea of pid randomization. > > > +#define PID_SYSCTL_UP 102400 > Why choose this particular value? If i remember correctly the underlying > type of pid_t is int32_t. What is the reason to not use 2^31 (-2) as the > upper bound? > > I admit there were a bit arbitrary values (i.e. on FreeBSD it is 1000 as lower bound and 99999 as upper limit ...), although I thought afterwards to make initial values settable via kernel config. But afterwards I understand you re all reluctant about making it settable via sysctl. So let's drop it ... > > + > > #define SESS_LEADER(pr) ((pr)->ps_session->s_leader == (pr)) > > #define SESSHOLD(s) ((s)->s_count++) > > #define SESSRELE(s) do { > \ > > > I agree with Owain, that changing PID_MAX, if it is necessary, should be > done globally and not with a sysctl. Do you have any evidence showing > that the pid space is too small? > > I would be more comfortable if the number was slightly bigger (tedu@ himself planned to increase it as some points if I remember well) regarding predictability. > cheers, > natano > Thanks for answering somehow.
