From: Nikolay Borisov <kernel-6AxghH7DbtA@public.gmane.org>
To: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Cc: Nikolay Borisov
<n.borisov-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org>,
ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: [RFC PATCH 0/2] Containerise nproc count
Date: Tue, 8 Sep 2015 11:11:11 +0300 [thread overview]
Message-ID: <1441699873-26653-1-git-send-email-kernel@kyup.com> (raw)
From: Nikolay Borisov <n.borisov-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org>
Hello,
This is an initial try to have nproc count apply per-userns,
rather than per the global user struct. The implementation is
really simple - a hashtable holding uid->nproc mapping for each
id inside the respective namespace. In its current form I have also
left the debugging code so that people who want to have a play with
it can easily see what's happening.
Now, this is only an RFC and I'd like to gather your thoughts about
the semantics. Currently as it stands I have tested the patchset by
invoking multiple LXC containers, with identical uid mappings and
users with the same uid inside the containers and it was working
correctly.
There is an issue however, when using the unshare syscall and then doing
the mappings e.g. using "unshare -r" util from util-linux the initial process
(the one which have done the unsharing) is accounted to the overflowuid but
then again when exiting from the resulting shell the UID for user 0 is being
freed which causes the BUG_ON in nsuser_nproc_dec to trigger. My initial idea
for fixing this was to add code which upon writing to /proc/[pid]/uid_map
would map all current processes from overflowuid to the 'ns->uid_map.extent[0].first'.
This was working correctly but it was breaking the use case of lxc, since lxc is
changing the uids after creating the uid_mapping (maybe this is a deficiency in the
unshare util implementation?)
Another thing that needs improving is the locking occuring on the nsuser_nproc_hash,
since in its current coarse-grained form it is serialisign process/thread creation on
a per-usernamespace basis.
I'm happy to discuss any concerns and improvements that people might have
regarding this patchset.
Nikolay Borisov (2):
userns: Implement per-userns nproc infrastructure
userns/nproc: Add hooks for userns nproc management
include/linux/user_namespace.h | 15 +++++-
kernel/cred.c | 36 +++++++++++++-
kernel/exit.c | 9 ++++
kernel/fork.c | 33 ++++++++++---
kernel/user.c | 3 ++
kernel/user_namespace.c | 105 +++++++++++++++++++++++++++++++++++++++++
6 files changed, 192 insertions(+), 9 deletions(-)
--
2.5.0
WARNING: multiple messages have this Message-ID (diff)
From: Nikolay Borisov <kernel@kyup.com>
To: containers@lists.linux-foundation.org
Cc: ebiederm@xmission.com, linux-kernel@vger.kernel.org,
Nikolay Borisov <n.borisov@siteground.com>
Subject: [RFC PATCH 0/2] Containerise nproc count
Date: Tue, 8 Sep 2015 11:11:11 +0300 [thread overview]
Message-ID: <1441699873-26653-1-git-send-email-kernel@kyup.com> (raw)
From: Nikolay Borisov <n.borisov@siteground.com>
Hello,
This is an initial try to have nproc count apply per-userns,
rather than per the global user struct. The implementation is
really simple - a hashtable holding uid->nproc mapping for each
id inside the respective namespace. In its current form I have also
left the debugging code so that people who want to have a play with
it can easily see what's happening.
Now, this is only an RFC and I'd like to gather your thoughts about
the semantics. Currently as it stands I have tested the patchset by
invoking multiple LXC containers, with identical uid mappings and
users with the same uid inside the containers and it was working
correctly.
There is an issue however, when using the unshare syscall and then doing
the mappings e.g. using "unshare -r" util from util-linux the initial process
(the one which have done the unsharing) is accounted to the overflowuid but
then again when exiting from the resulting shell the UID for user 0 is being
freed which causes the BUG_ON in nsuser_nproc_dec to trigger. My initial idea
for fixing this was to add code which upon writing to /proc/[pid]/uid_map
would map all current processes from overflowuid to the 'ns->uid_map.extent[0].first'.
This was working correctly but it was breaking the use case of lxc, since lxc is
changing the uids after creating the uid_mapping (maybe this is a deficiency in the
unshare util implementation?)
Another thing that needs improving is the locking occuring on the nsuser_nproc_hash,
since in its current coarse-grained form it is serialisign process/thread creation on
a per-usernamespace basis.
I'm happy to discuss any concerns and improvements that people might have
regarding this patchset.
Nikolay Borisov (2):
userns: Implement per-userns nproc infrastructure
userns/nproc: Add hooks for userns nproc management
include/linux/user_namespace.h | 15 +++++-
kernel/cred.c | 36 +++++++++++++-
kernel/exit.c | 9 ++++
kernel/fork.c | 33 ++++++++++---
kernel/user.c | 3 ++
kernel/user_namespace.c | 105 +++++++++++++++++++++++++++++++++++++++++
6 files changed, 192 insertions(+), 9 deletions(-)
--
2.5.0
next reply other threads:[~2015-09-08 8:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-08 8:11 Nikolay Borisov [this message]
2015-09-08 8:11 ` [RFC PATCH 0/2] Containerise nproc count Nikolay Borisov
[not found] ` <1441699873-26653-1-git-send-email-kernel-6AxghH7DbtA@public.gmane.org>
2015-09-08 8:11 ` [RFC PATCH 1/2] userns: Implement per-userns nproc infrastructure Nikolay Borisov
2015-09-08 8:11 ` Nikolay Borisov
2015-09-08 8:11 ` [RFC PATCH 2/2] userns/nproc: Add hooks for userns nproc management Nikolay Borisov
2015-09-08 8:11 ` Nikolay Borisov
2015-09-08 15:02 ` [RFC PATCH 0/2] Containerise nproc count Eric W. Biederman
2015-09-08 15:02 ` Eric W. Biederman
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=1441699873-26653-1-git-send-email-kernel@kyup.com \
--to=kernel-6axghh7dbta@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=n.borisov-/eCPMmvKun9pLGFMi4vTTA@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.