> KJ Tsanaktsidis <ktsanaktsidis@xxxxxxxxxxx> hat am 19. August 2018 um 02:41 > geschrieben: > > > On Sat, Aug 18, 2018 at 1:17 AM Jakub Wilk <jwilk@xxxxxxxxx> wrote: > > > > I reproduced this on Linux 4.17. As one would expect, this happens also > > with fork(2). > > > > This seems to contradict the fork(2) man page, which says that EAGAIN is > > returned when “the maximum number of PIDs, /proc/sys/kernel/pid_max, was > > reached”. > > I took a look at the fork manpage, which says that EAGAIN can be returned for > four reasons - because of pid_max (which seems to be wrong), because of > thread-max, because of RLIMIT_NPROC, and because of cgroup pids.max. I > checked all of these cases on my clone test program and they all return EAGAIN > except for the pid_max case, which returns ENOSPC. > > The clone(2) docs say that EAGAIN is returned if "Too many process are already > running; see fork(2)", which seems adequate to cover this off. > > I guess I should submit a second patch to remove pid_max from the list of > EAGAIN cases in fork(2) and mention it returns ENOSPC instead? > I would suggest sending this to the Linux Test Project and the kernel ML. I do not think this is intentional. re, wh
