So to close the loop on this, I sent a patch to make clone(2) and fork(2) return EAGAIN as documented, and it's been merged into the -mm tree and I think is being considered for backporting to stable kernels as well. See https://lkml.org/lkml/2018/9/3/345 Thanks for suggesting that I look at fixing the behaviour, rather than fixing the docs! Are there any other documentation fixups that would be needed now (perhaps to say that it returned ENOSPC in some kernel versions?) or is it all working as specified now and nothing else needs to be done? On Mon, Aug 20, 2018 at 12:07 AM Walter Harms <wharms@xxxxxx> wrote: > > > > > 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 >
