From: Andrew Morton <akpm@linux-foundation.org>
To: Andrey Wagin <avagin@gmail.com>
Cc: linux-kernel@vger.kernel.org, Oleg Nesterov <oleg@redhat.com>,
Cyrill Gorcunov <gorcunov@openvz.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Pavel Emelyanov <xemul@parallels.com>
Subject: Re: [PATCH] pidns: limit the nesting depth of pid namespaces
Date: Wed, 24 Oct 2012 12:46:07 -0700 [thread overview]
Message-ID: <20121024124607.43f599e8.akpm@linux-foundation.org> (raw)
In-Reply-To: <CANaxB-xVVmQaCze=4+SaLbwkbJYxBwjbzF0hWX+Js94veWxj3w@mail.gmail.com>
On Wed, 24 Oct 2012 09:38:57 +0400
Andrey Wagin <avagin@gmail.com> wrote:
> >
> > I think that returning -ENOMEM in response to an excessive nesting
> > attempt is misleading - the system *didn't* run out of memory. EINVAL
> > is better?
>
> I chose ENOMEM by analogy with max_pid. When a new PID can not be
> allocated, ENOMEM is returned too.
I don't know what this means - please be carefully specific when
identifying kernel code.
If you're referring to kernel/pid.c:alloc_pid() then -ENOMEM is
appropriate there, because a failure *is* caused by memory allocation
failure.
But ENOMEM isn't appropriate for nesting-depth-exceeded - we shouldn't
tell the user "you ran out of memory" when he didn't! -EINVAL isn't
really appropriate either ("Invalid argument") but it has become a
general you-screwed-up catchall and seems to me to be the most
appropriate errno we have available.
next prev parent reply other threads:[~2012-10-24 19:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-12 12:30 [PATCH] pidns: limit the nesting depth of pid namespaces Andrew Vagin
2012-10-19 14:25 ` Andrey Wagin
2012-10-20 15:21 ` Oleg Nesterov
2012-10-23 23:56 ` Andrew Morton
2012-10-24 5:38 ` Andrey Wagin
2012-10-24 19:46 ` Andrew Morton [this message]
2012-10-25 15:02 ` Andrey Wagin
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=20121024124607.43f599e8.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=avagin@gmail.com \
--cc=ebiederm@xmission.com \
--cc=gorcunov@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=xemul@parallels.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.