All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt-XAri/EZa3C4vJsYlp49lxw@public.gmane.org>
To: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Subject: Re: 2.6.35: unshare(NEWNS) does not work inside a container anymore?
Date: Thu, 02 Sep 2010 13:20:45 +0400	[thread overview]
Message-ID: <4C7F6C6D.5060107@msgid.tls.msk.ru> (raw)
In-Reply-To: <4C7CE137.5090009-Gdu+ltImwkhes2APU0mLOQ@public.gmane.org>

31.08.2010 15:02, Michael Tokarev wrote:
> I just noticed a regression - immediately after updating
> kernel from 2.6.32 to 2.6.35 (I skipped .33 and .34).
> Namely, unshare(CLONE_NEWNS) stopped workin from within
> a container, like this:
> 
> unshare(CLONE_NEWNS)              = -1 EINVAL (Invalid argument)
> 
> There's no other fancy stuff going on around, just plain
> unshare and exec a new shell.
> 
> What's wrong with 2.6.35 in this context?

So, after discussing this on IRC and doing some discovery,
it turned out to be new (in 2.6.35) cgroup subsystem --
block I/O controller (CONFIG_BLK_CGROUP).  This one does
not allow more than 1 level of nesting, so, for example,
it is impossible to create a subdirectory in another
cgroup dir in cgroupfs:

 mkdir /dev/cgroup/foo  -- this one succeeds, but
 mkdir /dev/cgroup/foo/bar -- this fails as long
as blkio mount option is enabled.  Once disabled, it
works again.

In 2.6.35 block/blk-cgroup.c, blkiocg_create() there's the
following code:

  /* Currently we do not support hierarchy deeper than two level (0,1) */
  if (parent != cgroup->top_cgroup)
          return ERR_PTR(-EINVAL);

In 2.6.36-tobe it were changed to

          return ERR_PTR(-EPERM);

but the issue remains anyway.  What is problematic here
is that blkio is different from all other cgroups in
this very respect (not allowing nesting), but there's
no indication of this fact anywhere.  At least, the
above quoted place warranrs a WARN() or WARN_ONCE()
to tell the user what's going on - or else it's very
difficult to debug.

Speaking of real solution, it looks like disallowing
nesting should be done in a different way.  Maybe
allow creation of a subcontainer but reset the limits
in there and catch attempts to set them, - I dunno.
Or, don't clone whole cgroup hierarchy on CLONE_NEWNS
only.

Current situation is too restrictive IMHO - blkio
controller is useful for a container like LXC, but
currently it implies that one can't create even a
new filesystem namespace within it.

Thanks.

/mjt

      parent reply	other threads:[~2010-09-02  9:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-31 11:02 2.6.35: unshare(NEWNS) does not work inside a container anymore? Michael Tokarev
     [not found] ` <4C7CE137.5090009-Gdu+ltImwkhes2APU0mLOQ@public.gmane.org>
2010-09-01 16:28   ` Serge E. Hallyn
     [not found]     ` <20100901162833.GA13274-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
2010-09-01 17:27       ` Michael Tokarev
     [not found]         ` <4C7E8D1B.2060204-Gdu+ltImwkhes2APU0mLOQ@public.gmane.org>
2010-09-01 19:41           ` Serge E. Hallyn
     [not found]             ` <20100901194136.GA13918-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
2010-09-01 19:53               ` Michael Tokarev
2010-09-02  9:20   ` Michael Tokarev [this message]

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=4C7F6C6D.5060107@msgid.tls.msk.ru \
    --to=mjt-xari/eza3c4vjsylp49lxw@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    /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.