Skip to content

Commit

Permalink
pid: make ENOMEM return value more obvious
Browse files Browse the repository at this point in the history
The alloc_pid() codepath used to be simpler. With the introducation of the
ability to choose specific pids in 49cb2fc ("fork: extend clone3() to
support setting a PID") it got more complex. It hasn't been super obvious
that ENOMEM is returned when the pid namespace init process/child subreaper
of the pid namespace has died. As can be seen from multiple attempts to
improve this see e.g. [1] and most recently [2].
We regressed returning ENOMEM in [3] and [2] restored it. Let's add a
comment on top explaining that this is historic and documented behavior and
cannot easily be changed.

[1]: 35f71bc ("fork: report pid reservation failure properly")
[2]: b26ebfe ("pid: Fix error return value in some cases")
[3]: 49cb2fc ("fork: extend clone3() to support setting a PID")
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
  • Loading branch information
Christian Brauner committed Mar 9, 2020
1 parent b26ebfe commit 10dab84
Showing 1 changed file with 8 additions and 0 deletions.
8 changes: 8 additions & 0 deletions kernel/pid.c
Original file line number Diff line number Diff line change
Expand Up @@ -247,6 +247,14 @@ struct pid *alloc_pid(struct pid_namespace *ns, pid_t *set_tid,
tmp = tmp->parent;
}

/*
* ENOMEM is not the most obvious choice especially for the case
* where the child subreaper has already exited and the pid
* namespace denies the creation of any new processes. But ENOMEM
* is what we have exposed to userspace for a long time and it is
* documented behavior for pid namespaces. So we can't easily
* change it even if there were an error code better suited.
*/
retval = -ENOMEM;

if (unlikely(is_child_reaper(pid))) {
Expand Down

0 comments on commit 10dab84

Please sign in to comment.