On 4/5/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
The approach I am on currently doesnt deal with dynamically loaded
modules ..Partly because it allows subsystem ids to be compile-time
decided
Yes, that part is definitely a good idea, since it removes one of the
potential performance co
On Thu, Apr 05, 2007 at 10:27:52PM +0530, Srivatsa Vaddagiri wrote:
> Ok ..by posting rcfs patches, I didn't mean to introduce a "yours" and
> "mine" rift ..honestly. In fact you would notice that they have your
> (sole) copyright still on them! It took me just two days to convert over the
> patch
On Wed, Apr 04, 2007 at 11:57:18AM -0700, Paul Menage wrote:
> > Very true. That's a bug and can be rectified. Atm however in my patch
> > stack, I have dropped this whole find_nsproxy() and instead create a new
> > nsproxy whenever tasks move ..Not the best I agree on long run.
>
> Or even short
On Thu, Apr 05, 2007 at 07:13:37AM -0700, Paul Menage wrote:
> > ns should have a refcount of 1 to begin with.
>
> Right - that's my point, you're effectively passing the initial
> refcount of the nsproxy to the container directory's d_fsdata
> reference.
sure ..
> > Basically I am struggling to
On 4/5/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> If the container directory were to have no refcount on the nsproxy, so
> the initial refcount was 0,
No it should be 1.
mkdir H1/foo
rcfs_create()
ns = dup_namespaces(parent);
On Thu, Apr 05, 2007 at 06:13:25PM +0530, Srivatsa Vaddagiri wrote:
> Lets go back to the f_bc example here for a moment. Lets say T1 was in C1 and
> opened file f1. f1->f_bc points to C1->beancounter.
>
> T1 moves from C1 -> C2, but f1 is not migrated.
> C1->beancounter.count stays at 1 (to acc
On Thu, Apr 05, 2007 at 02:29:32AM -0700, Paul Menage wrote:
> >I don't understand this.
>
> I meant for each active hierarchy, sorry. But thinking about this
> further, I think you're right - since every container directory points
> to an nsproxy that contains its own subsystems groups for subsys
On Wed, Apr 04, 2007 at 11:48:57PM -0700, Paul Menage wrote:
> >rcfs_task_count will essentially return number of tasks pointing to A1
> >thr' their nsproxy->ctlr_data[BC_ID].
>
> One small issue with the (last posted) version of your patch is that
> it doesn't take into account the refcounts from
On 4/5/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
You mean dentry->d_fsdata pointing to nsproxy should take a ref count on
nsproxy? afaics it is not needed as long as you first drop the dentry
before freeing associated nsproxy.
You get the nsproxy object from dup_namespaces(), which wil
On 4/4/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
On Wed, Apr 04, 2007 at 07:57:40PM -0700, Paul Menage wrote:
> >Firstly, this is not a unique problem introduced by using ->nsproxy.
> >Secondly we have discussed this to some extent before
> >(http://lkml.org/lkml/2007/2/13/122). Essential
On Wed, Apr 04, 2007 at 07:57:40PM -0700, Paul Menage wrote:
> >Firstly, this is not a unique problem introduced by using ->nsproxy.
> >Secondly we have discussed this to some extent before
> >(http://lkml.org/lkml/2007/2/13/122). Essentially if we see zero tasks
> >sharing a resource object pointe
On Thu, Apr 05, 2007 at 12:09:50PM +0530, Srivatsa Vaddagiri wrote:
> IF (note that /if/ again) the count returned is zero, then my point was
> we can destroy nsproxy behind foo and also B1, not worrying about a
> 'struct file' still pointing to B1. This stems from the fact that you
> cannot have a
On 4/4/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> - how do you handle additional reference counts on subsystems? E.g.
> beancounters wants to be able to associate each file with the
> container that owns it. You need to be able to lock out subsystems
> from taking new reference counts on
On 4/4/07, Paul Menage <[EMAIL PROTECTED]> wrote:
The current code creates such arrays when it needs an atomic snapshot
of the set of tasks in the container (e.g. for reporting them to
userspace or updating the mempolicies of all the tasks in the case of
cpusets). It may be possible to do it by t
On 4/4/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
In addition there appear to be some weird assumptions (an array with
one member per task_struct) in the group. The pid limit allows
us millions of task_structs if the user wants it. A several megabyte
array sounds like a completely unsui
Next time I have a moment I will try and take a closer look. However
currently these approaches feel like there is some unholy coupling going
on between different things.
In addition there appear to be some weird assumptions (an array with
one member per task_struct) in the group. The pid limit
On 4/4/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
On Wed, Apr 04, 2007 at 12:00:07AM -0700, Paul Menage wrote:
> OK, looking at that, I see a few problems related to the use of
> nsproxy and lack of a container object:
Before we (and everyone else!) gets lost in this thread, let me say so
On Wed, Apr 04, 2007 at 10:56:43PM +0530, Srivatsa Vaddagiri wrote:
> I think the null grouping as defined so far is very fuzzy ..How would
> the kernel use this grouping, which would require reserving N pointers
> in 'struct container_group'/'struct nsproxy'?
aside from needing to support 'cat t
On Wed, Apr 04, 2007 at 12:00:07AM -0700, Paul Menage wrote:
> OK, looking at that, I see a few problems related to the use of
> nsproxy and lack of a container object:
Before we (and everyone else!) gets lost in this thread, let me say somethings
upfront:
- From my understanding, task_struct is
On 4/3/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
On Tue, Apr 03, 2007 at 09:04:59PM -0700, Paul Menage wrote:
> Have you posted the cpuset implementation over your system yet?
Yep, here:
http://lists.linux-foundation.org/pipermail/containers/2007-March/001497.html
For some reason, the
On Tue, Apr 03, 2007 at 09:04:59PM -0700, Paul Menage wrote:
> Have you posted the cpuset implementation over your system yet?
Yep, here:
http://lists.linux-foundation.org/pipermail/containers/2007-March/001497.html
For some reason, the above mail didnt make it into lkml (maybe it
exceeded the m
On 4/3/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
User space queries like "what is the cpuset to which this task belongs",
where the answer needs to be something of the form "/dev/cpuset/C1"?
The patches address that requirement atm by having a dentry pointer in
struct cpuset itself.
Hav
vatsa wrote:
> User space queries like "what is the cpuset to which this task belongs",
> where the answer needs to be something of the form "/dev/cpuset/C1"?
I think that answer should be of the form "/C1", and not include the
cpuset file system mount point ... though for the purposes of the
pres
On Tue, Apr 03, 2007 at 10:49:49AM -0700, Paul Menage wrote:
> > Why is the hierarchy bit important here? Usually controllers need to
> > know "tell me what cpuset this task belongs to", which is answered
> > by tsk->nsproxy->ctlr_data[CPUSET_ID].
>
> I was thinking of queries from userspace.
Use
On 4/3/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> (Or more generally, tell which container a task is
> in for a given hierarchy?)
Why is the hierarchy bit important here? Usually controllers need to
know "tell me what cpuset this task belongs to", which is answered
by tsk->nsproxy->ctlr
On Tue, Apr 03, 2007 at 10:30:28AM -0700, Paul Menage wrote:
> So how do you implement something like the /proc//container info
> file in my patches?
I havent implemented that yet, so I will look at your next question:
> (Or more generally, tell which container a task is
> in for a given hierarc
On 4/3/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
Hmm no .. I currently have nsproxy having just M additional pointers, where
M is the maximum number of resource controllers and a single dentry
pointer.
So how do you implement something like the /proc//container info
file in my patches?
On 4/3/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
On Tue, Apr 03, 2007 at 10:10:35AM -0700, Paul Menage wrote:
> Agreed. So I'm not saying it's fundamentally a bad idea - just that
> merging container_group and nsproxy is a fairly simple space
> optimization that could easily be done later
On Tue, Apr 03, 2007 at 10:10:35AM -0700, Paul Menage wrote:
> Agreed. So I'm not saying it's fundamentally a bad idea - just that
> merging container_group and nsproxy is a fairly simple space
> optimization that could easily be done later.
IMHO, if we agree that space optimization is important,
On Tue, Apr 03, 2007 at 10:10:35AM -0700, Paul Menage wrote:
> > Even if nsproxy objects are made larger a bit, the number of such object
> > will
>
> You're not making them "a bit" larger, you're adding N+M pointers
> where N is the number of container hierarchies and M is the number of
> subsys
On 4/3/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
On Tue, Apr 03, 2007 at 09:52:35AM -0700, Paul Menage wrote:
> I'm not saying "let's use nsproxy" - I'm not yet convinced that the
> lifetime/mutation/correlation rate of a pointer in an nsproxy is
> likely to be the same as for a container
On Tue, Apr 03, 2007 at 09:52:35AM -0700, Paul Menage wrote:
> I'm not saying "let's use nsproxy" - I'm not yet convinced that the
> lifetime/mutation/correlation rate of a pointer in an nsproxy is
> likely to be the same as for a container subsystem; if not, then
> reusing nsproxy could actually i
On 4/3/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
On Tue, Apr 03, 2007 at 08:45:37AM -0700, Paul Menage wrote:
> Whilst I've got no objection in general to using nsproxy rather than
> the container_group object that I introduced in my latest patches,
So are you saying lets (re-)use tsk->n
On Tue, Apr 03, 2007 at 08:45:37AM -0700, Paul Menage wrote:
> Whilst I've got no objection in general to using nsproxy rather than
> the container_group object that I introduced in my latest patches,
So are you saying lets (re-)use tsk->nsproxy but also retain 'struct
container' to store general
Paul Menage wrote:
> On 4/3/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
>
>>But frankly I don't know where we stand right now wrt the containers
>>patches. Do most people want to go with Vatsa's latest version moving
>>containers into nsproxy? Has any other development been going on?
>>Paul,
On Tue, Apr 03, 2007 at 08:45:37AM -0700, Paul Menage wrote:
> Whilst I've got no objection in general to using nsproxy rather than
> the container_group object that I introduced in my latest patches, I
> think that Vatsa's approach of losing the general container object is
> flawed, since it loses
On Tue, Apr 03, 2007 at 10:32:20AM -0500, Serge E. Hallyn wrote:
> But frankly I don't know where we stand right now wrt the containers
> patches. Do most people want to go with Vatsa's latest version moving
> containers into nsproxy?
> Has any other development been going on?
I have another u
Quoting Paul Menage ([EMAIL PROTECTED]):
> On 4/3/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
> >
> >But frankly I don't know where we stand right now wrt the containers
> >patches. Do most people want to go with Vatsa's latest version moving
> >containers into nsproxy? Has any other developme
On 4/3/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
But frankly I don't know where we stand right now wrt the containers
patches. Do most people want to go with Vatsa's latest version moving
containers into nsproxy? Has any other development been going on?
Paul, have you made any updates?
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> Srivatsa Vaddagiri <[EMAIL PROTECTED]> writes:
>
> > On Mon, Apr 02, 2007 at 09:09:39AM -0500, Serge E. Hallyn wrote:
> >> Losing the directory isn't a big deal though. And both unsharing a
> >> namespace (which causes a ns_container_clone) and mou
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> Srivatsa Vaddagiri <[EMAIL PROTECTED]> writes:
>
> > On Mon, Apr 02, 2007 at 09:09:39AM -0500, Serge E. Hallyn wrote:
> >> Losing the directory isn't a big deal though. And both unsharing a
> >> namespace (which causes a ns_container_clone) and mou
On Mon, Apr 02, 2007 at 12:02:35PM -0600, Eric W. Biederman wrote:
> > If we loose directories, then we don't have a way to manage the
> > task-group it represents thr' the filesystem interface, so I consider
> > that bad. As we agree, this will not be an issue if initrd
> > mounts the ns hierarchy
Srivatsa Vaddagiri <[EMAIL PROTECTED]> writes:
> On Mon, Apr 02, 2007 at 09:09:39AM -0500, Serge E. Hallyn wrote:
>> Losing the directory isn't a big deal though. And both unsharing a
>> namespace (which causes a ns_container_clone) and mounting the hierarchy
>> are done by userspace, so if for s
On Mon, Apr 02, 2007 at 09:09:39AM -0500, Serge E. Hallyn wrote:
> Losing the directory isn't a big deal though. And both unsharing a
> namespace (which causes a ns_container_clone) and mounting the hierarchy
> are done by userspace, so if for some installation it is a big deal,
> the init scripts
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
> On Mon, Feb 12, 2007 at 12:15:28AM -0800, [EMAIL PROTECTED] wrote:
> > +int ns_container_clone(struct task_struct *tsk)
> > +{
> > + return container_clone(tsk, &ns_subsys);
> > +}
>
> This function is a no-op if ns hierarchy is not mounted at th
On Mon, Feb 12, 2007 at 12:15:28AM -0800, [EMAIL PROTECTED] wrote:
> +int ns_container_clone(struct task_struct *tsk)
> +{
> + return container_clone(tsk, &ns_subsys);
> +}
This function is a no-op if ns hierarchy is not mounted at this point.
This would mean that we will miss out on some dire
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
> On Mon, Mar 26, 2007 at 04:57:55PM -0500, Serge E. Hallyn wrote:
> > That is still not true, see kernel/utsname:copy_utsname().
> >
> > Now you might have run a userspace testcase in a kernel with
> > CONFIG_UTS_NS=n, which at the moment erroneousl
On Mon, Mar 26, 2007 at 04:57:55PM -0500, Serge E. Hallyn wrote:
> That is still not true, see kernel/utsname:copy_utsname().
>
> Now you might have run a userspace testcase in a kernel with
> CONFIG_UTS_NS=n, which at the moment erroneously returns 0 rather than
> -EINVAL when you clone(CLONE_NEW
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
> On Sat, Mar 24, 2007 at 10:35:37AM +0530, Srivatsa Vaddagiri wrote:
> > > +static int ns_create(struct container_subsys *ss, struct container *cont)
> > > +{
> > > + struct nscont *ns;
> > > +
> > > + if (!capable(CAP_SYS_ADMIN))
> > > + ret
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
> On Mon, Feb 12, 2007 at 12:15:28AM -0800, [EMAIL PROTECTED] wrote:
> > +/*
> > + * Rules: you can only create a container if
> > + * 1. you are capable(CAP_SYS_ADMIN)
> > + * 2. the target container is a descendant of your own container
> >
On Sat, Mar 24, 2007 at 10:35:37AM +0530, Srivatsa Vaddagiri wrote:
> > +static int ns_create(struct container_subsys *ss, struct container *cont)
> > +{
> > + struct nscont *ns;
> > +
> > + if (!capable(CAP_SYS_ADMIN))
> > + return -EPERM;
>
> Does this check break existing namespac
On Mon, Feb 12, 2007 at 12:15:28AM -0800, [EMAIL PROTECTED] wrote:
> +/*
> + * Rules: you can only create a container if
> + * 1. you are capable(CAP_SYS_ADMIN)
> + * 2. the target container is a descendant of your own container
> + */
> +static int ns_create(struct container_subsys *ss, st
When a task enters a new namespace via a clone() or unshare(), a new
container is created and the task moves into it. Developed by Serge
Hallyn <[EMAIL PROTECTED]>, adapted by Paul Menage <[EMAIL PROTECTED]>
---
include/linux/nsproxy.h |6 ++
init/Kconfig|9 +++
kernel/Makefil
53 matches
Mail list logo
