From: ebiederm@xmission.com (Eric W. Biederman)
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Josh Boyer <jwboyer@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>, Mel Gorman <mgorman@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: Odd ENOMEM being returned in 3.8-rcX
Date: Tue, 12 Feb 2013 02:34:15 -0800 [thread overview]
Message-ID: <87obfphlco.fsf@xmission.com> (raw)
In-Reply-To: <20130211155701.e7968e64.akpm@linux-foundation.org> (Andrew Morton's message of "Mon, 11 Feb 2013 15:57:01 -0800")
Andrew Morton <akpm@linux-foundation.org> writes:
> On Fri, 08 Feb 2013 12:13:09 -0800
> ebiederm@xmission.com (Eric W. Biederman) wrote:
>
>> If mock has called unshare(CLONE_NEWPID). And then forked a process and
>> that process exited, and then forked anothe process that second and all
>> subsequent fork calls will fail with -ENOMEM (because init has exited in
>> the pid namespace). -ENOMEM will be generated because of a failure of
>> alloc_pid.
>
> Can we please fix this? The system is *not* out of memory and it's
> wildly misleading to report this to userspace.
>
> If alloc_pid() can fail for multiple reasons then it should be
> returning an ERR_PTR on failure, not NULL.
We might be able to fix this.
alloc_pid causing fork to fail with ENOMEM when there are simply not
enough pids available to use is a long standing failure mode, and error
code.
I believe to change this responsibily you would have read a lot of
programs to see if fork failing with an additional error code would be
handled or if things would break in subtle ways. There would need to be
research to see what posix says about this, and the posix view on fork
would have any impact on this in any way.
Furthermore this error is a resource shortage, so ENOMEM isn't even
exactly wrong.
I can understand the problem but I totally don't care enough to push an
ABI change like that through.
Eric
next prev parent reply other threads:[~2013-02-12 10:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-07 21:57 Odd ENOMEM being returned in 3.8-rcX Josh Boyer
2013-02-07 22:15 ` Andrew Morton
2013-02-08 0:35 ` Josh Boyer
2013-02-08 18:19 ` Josh Boyer
2013-02-08 20:13 ` Eric W. Biederman
2013-02-08 20:23 ` Josh Boyer
2013-02-08 20:45 ` Eric W. Biederman
2013-02-08 21:27 ` Josh Boyer
2013-02-08 22:05 ` Eric W. Biederman
2013-02-08 22:40 ` Clark Williams
2013-02-08 22:10 ` Clark Williams
2013-02-08 22:40 ` Eric W. Biederman
2013-02-08 22:56 ` Clark Williams
2013-02-08 22:12 ` Josh Boyer
2013-02-11 23:57 ` Andrew Morton
2013-02-12 10:34 ` Eric W. Biederman [this message]
2013-02-08 20:18 ` Josh Boyer
2013-02-08 20:36 ` Eric W. Biederman
2013-02-08 20:40 ` Josh Boyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87obfphlco.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=jwboyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).