Skip to content

Commit 10dab84

Browse files
author
Christian Brauner
committed
pid: make ENOMEM return value more obvious
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 <[email protected]>
1 parent b26ebfe commit 10dab84

File tree

1 file changed

+8
-0
lines changed

1 file changed

+8
-0
lines changed

kernel/pid.c

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -247,6 +247,14 @@ struct pid *alloc_pid(struct pid_namespace *ns, pid_t *set_tid,
247247
tmp = tmp->parent;
248248
}
249249

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

252260
if (unlikely(is_child_reaper(pid))) {

0 commit comments

Comments
 (0)