Skip to content

Commit addcb1d

Browse files
committed
Merge tag 'for-linus-2020-03-10' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux
Pull thread fix from Christian Brauner: "This contains a single fix for a regression which was introduced when we introduced the ability to select a specific pid at process creation time. When this feature is requested, the error value will be set to -EPERM after exiting the pid allocation loop. This caused EPERM to be returned when e.g. the init process/child subreaper of the pid namespace has already died where we used to return ENOMEM before. The first patch here simply fixes the regression by unconditionally setting the return value back to ENOMEM again once we've successfully allocated the requested pid number. This should be easy to backport to v5.5. The second patch adds a comment explaining that we must keep returning ENOMEM since we've been doing it for a long time and have explicitly documented this behavior for userspace. This seemed worthwhile because we now have at least two separate example where people tried to change the return value to something other than ENOMEM (The first version of the regression fix did that too and the commit message links to an earlier patch that tried to do the same.). I have a simple regression test to make sure we catch this regression in the future but since that introduces a whole new selftest subdir and test files I'll keep this for v5.7" * tag 'for-linus-2020-03-10' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux: pid: make ENOMEM return value more obvious pid: Fix error return value in some cases
2 parents 36feb99 + 10dab84 commit addcb1d

File tree

1 file changed

+10
-0
lines changed

1 file changed

+10
-0
lines changed

kernel/pid.c

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -247,6 +247,16 @@ 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+
*/
258+
retval = -ENOMEM;
259+
250260
if (unlikely(is_child_reaper(pid))) {
251261
if (pid_ns_prepare_proc(ns))
252262
goto out_free;

0 commit comments

Comments
 (0)