From: "Eric W. Biederman" <ebiederm@xmission.com>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Containers <containers@lists.osdl.org>,
clg@fr.ibm.com, linux-kernel@vger.kernel.org,
Pavel Emelyanov <xemul@openvz.org>
Subject: Re: [RFC][PATCH 0/7] Clone PTS namespace
Date: Thu, 10 Apr 2008 00:36:20 -0700 [thread overview]
Message-ID: <1207812980.7509.25.camel@x61.ebiederm.org> (raw)
In-Reply-To: <20080410015955.GA18227@sergelap.austin.rr.com>
On Wed, 2008-04-09 at 20:59 -0500, Serge E. Hallyn wrote:
> Feh, so of course sysfs would have the most interactions for a device
> namespace, but now we have pty, network, and user namespace all needing
> some sort of sysfs solution. For a quickfix for
> CONFIG_USER_SCHED+CONFIG_USER_NS, I just moved /sys/kernel/uids/<uid>
> to /sys/kernel/uids/<userns_address>/<uid>. But what would be a *good*
> general solution?
>
> ln -s /sys /proc/self/sys?
LOL
In /proc I prefer the /proc/self approach because we can do it and it is
just much easier to setup and use. (Plus we have weird problems if we
try and capture more then the pid namespace).
For other filesystems the only really viable option is to capture
namespaces at mount time, as we are doing for devpts and proc with
respect to the pid namespace.
For the network namespace where it is very much more then a single
directory with symlinks from physical devices pointing at logical
network interfaces.
My last effort in that area was ok'd by Tejun lightly tested by a few
others and misplaced by gregkh so I don't think we have a real problem
with resurrecting those patches cleaning them up a bit and merging them.
The biggest gotcha with sysfs is that the VFS locking for the dcache
is in the wrong order for distributed filesystems, where we would like
to make the change atomically on the server and them make the change in
the local cache. Or in this case the sysfs internal data structures.
The truly nasty case is supporting rename (as sysfs does) as the VFS
is not at all happy if you just punt and shoot down the dentries and
instantiate new ones.
I'm hoping to be able to get back at this in the week or so as things
settle down from my move. My last patches should be in my proof of
concept network namespace tree, if they don't show up elsewhere.
It isn't my perception that we have a design problem rather, we just
need to move an important piece of code in a subtle and moderately
uninteresting direction for it's primary maintainer.
Further what I did for the network namespace should easily handle the
uid/gid namespace and should be a good starting place for a general
device namespace.
Eric
next prev parent reply other threads:[~2008-04-10 7:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-08 21:53 sukadev
2008-04-08 21:58 ` [RFC][PATCH 1/7]: Propagate error code from devpts_pty_new sukadev
2008-04-08 21:58 ` [RFC][PATCH 2/7]: Factor out PTY index allocation sukadev
2008-04-08 21:59 ` [RFC][PATCH 3/7]: Enable multiple mounts of /dev/pts sukadev
2008-04-08 21:59 ` [RFC][PATCH 4/7]: Allow mknod of ptmx and tty in devpts sukadev
2008-04-08 22:00 ` [RFC][PATCH 5/7]: Implement get_pts_ns() and put_pts_ns() sukadev
2008-04-08 22:00 ` [RFC][PATCH 6/7]: Determine pts_ns from a pty's inode sukadev
2008-04-08 22:00 ` [RFC][PATCH 7/7]: Enable cloning PTY namespaces sukadev
2008-04-09 0:53 ` [RFC][PATCH 0/7] Clone PTS namespace H. Peter Anvin
2008-04-09 16:23 ` sukadev
2008-04-09 18:01 ` H. Peter Anvin
2008-04-09 19:16 ` serge
2008-04-09 22:38 ` H. Peter Anvin
2008-04-09 22:15 ` Eric W. Biederman
2008-04-10 1:59 ` Serge E. Hallyn
2008-04-10 7:36 ` Eric W. Biederman [this message]
2008-04-10 16:44 ` Serge E. Hallyn
2008-04-10 20:58 ` sukadev
2008-04-22 14:25 ` Serge E. Hallyn
2008-04-22 18:53 ` Eric W. Biederman
2008-04-23 14:36 ` Serge E. Hallyn
2008-04-23 17:57 ` Serge E. Hallyn
2008-04-23 18:49 ` Eric W. Biederman
2008-04-25 19:21 ` Serge E. Hallyn
2008-04-25 19:47 ` Eric W. Biederman
2008-04-26 13:02 ` Serge E. Hallyn
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=1207812980.7509.25.camel@x61.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=clg@fr.ibm.com \
--cc=containers@lists.osdl.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=serue@us.ibm.com \
--cc=xemul@openvz.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®