[LTP] [v2 2/2] lib/tst_pid.c: Increase PIDS_RESERVED to avoid fork failure.

[Leo Liang]

Hi Cyril,

On Tue, Feb 14, 2023 at 04:09:52PM +0100, Cyril Hrubis wrote:
> Hi!
> > > > > > After Adjusting how we count used pid, we increase
> > > > > > the number of PIDS_RESERVED to void fork failure.
> > > > > nit: in this case I'd actually keep changes in single commit
> > > > > (otherwise first commit alone would break tests),
> > > > 
> > > > Do we get a different result from ps and parsing /proc? That sounds
> > > > strange...
> > > 
> > > I think that's because "ps -eT" would list threads with the same PID
> > > but with different SPID.
> > > 
> > > I get the following output on my VM.
> > > 
> > > ycliang@ubuntu01:~$ ps -eT | wc -l
> > > 170
> > > ycliang@ubuntu01:~$ ls -d /proc/[0-9]* | xargs -n1 | wc -l
> > > 127
> > 
> > Adjusting the RESERVED constant is then a lousy workaround that wouldn't
> > work for systems with many threads per process.
> > 
> > One alternative would be to open /proc/$PID/status and read the number
> > of threads from there. Should be as easy as one call to
> > SAFE_FILE_LINES_SCANF().
> 
> Thinking of it again using SAFE_FILE_LINES_SCANF() may be prone to a
> race where the process exits and the file disappears between the call to
> the readdir() and the open in the SAFE_FILE_LINES_SCANF() so I suppose
> that we should use just the FILE_LINES_SCANF() instead and add the
> threads value only if the call succeeded.

Thanks for the advice!
Will send a v3.

Just out of curiosity, is there any reason that we should do this in plain C ?
(Otherwise, we could drop this patchset and stay with the current implementation)

Best regards,
Leo

> 
> -- 
> Cyril Hrubis
> chrubis@suse.cz