From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Vagin <avagin@openvz.org>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Cyrill Gorcunov <gorcunov@openvz.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Pavel Emelyanov <xemul@parallels.com>
Subject: Re: [PATCH] pidns: limit a size of pid to one page
Date: Thu, 11 Oct 2012 20:39:22 +0200 [thread overview]
Message-ID: <20121011183922.GA6582@redhat.com> (raw)
In-Reply-To: <1349864654-1333268-1-git-send-email-avagin@openvz.org>
On 10/10, Andrew Vagin wrote:
>
> A size of pid depends on a level of pidns and now a level of pidns
> is not limited, so it can be more than one page.
>
> Looks reasonable, that it should be limited to a page size. On x86_64
> it will allow to create 125 nested pid namespaces. I don't know a
> usecase for which, it will be not enough. When someone finds a
> reasonable use case, we can add a config option or a sysctl parameter.
I think this makes sense.
Acked-by: Oleg Nesterov <oleg@redhat.com>
> In addition it will reduce effect of another problem, when we have many
> nested namespaces and the oldest one starts dying. zap_pid_ns_processe
> will be called for each namespace and find_vpid will be called for each
> process in a namespace. find_vpid will be called minimum max_level^2 / 2
> times. The reason of that is that when we found a bit in pidmap, we
> can't determine this pidns is top for this process or it isn't.
>
> vpid is a heavy operation, so a fork bomb, which create many nested
> namespace, can do a system inaccessible for a long time.
>
> For example my system becomes inaccessible for a few minutes with
> 4000 processes.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Oleg Nesterov <oleg@redhat.com>
> Cc: Cyrill Gorcunov <gorcunov@openvz.org>
> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> Cc: Pavel Emelyanov <xemul@parallels.com>
> Signed-off-by: Andrew Vagin <avagin@openvz.org>
> ---
> kernel/pid_namespace.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
> index b051fa6..bc822e6 100644
> --- a/kernel/pid_namespace.c
> +++ b/kernel/pid_namespace.c
> @@ -70,12 +70,18 @@ err_alloc:
> return NULL;
> }
>
> +/* Limit a size of pid to one page */
> +#define MAX_PID_NS_LEVEL ((PAGE_SIZE - sizeof(struct pid)) / sizeof(struct upid))
> +
> static struct pid_namespace *create_pid_namespace(struct pid_namespace *parent_pid_ns)
> {
> struct pid_namespace *ns;
> unsigned int level = parent_pid_ns->level + 1;
> int i, err = -ENOMEM;
>
> + if (level > MAX_PID_NS_LEVEL)
> + goto out;
> +
> ns = kmem_cache_zalloc(pid_ns_cachep, GFP_KERNEL);
> if (ns == NULL)
> goto out;
> --
> 1.7.1
>
next prev parent reply other threads:[~2012-10-11 18:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-10 10:24 Andrew Vagin
2012-10-11 18:39 ` Oleg Nesterov [this message]
2012-10-11 20:10 ` Andrew Morton
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=20121011183922.GA6582@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=avagin@openvz.org \
--cc=ebiederm@xmission.com \
--cc=gorcunov@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome