On Mon, Sep 10, 2007 at 11:38:10AM -0700, Paul Menage wrote:
> By definition any container (about to be renamed control group)
> subsystem is some kind of "controller" so that bit seems a bit
> redundant.
>
> Any reason not to just call it "cpu" or "cpu_sched"
Done (in the latest patch I sent a w
On Tue, Sep 11, 2007 at 12:28:51AM +0200, Dmitry Adamushko wrote:
> > + rq = task_rq_lock(tsk, &flags);
> > +
>
> I guess, update_rq_clock(rq) should be placed here.
>
> humm... do you really need deactivate/activate_task() here? 'rq' and
> p->se.load.weight stay unchanged so enqueue/dequeu
From: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
Subject: [PATCH 3/3] Signal semantics for pid namespaces
With support for multiple pid namespaces, each pid namespace has a
separate child reaper and this process needs some special handling
of signals.
- The child reaper should appear like
(This is Oleg's patch with my pid ns additions. Compiled and unit tested
on 2.6.23-rc4-mm1 with other patches in this set. Oleg pls update this
patch if necessary and sign-off)
---
Currently, /sbin/init is protected from unhandled signals by the
"current == child_reaper(current)" check in get_sig
Define some helper functions that will be used to implement signal semantics
with multiple pid namespaces.
is_current_in_ancestor_pid_ns(task)
TRUE iff active pid namespace of 'current' is an ancestor of
active pid namespace of @task.
is_current
Paul Menage wrote:
> On 9/7/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>> Thanks for doing this. We are building containerstats for
>> per container statistics. It would be really nice to provide
>> the statistics using that interface. I am not opposed to
>> memory.stat, but Paul Menage recommends
Cedric Le Goater [EMAIL PROTECTED] wrote:
| FYI,
|
| I just did a compile test on a 2.6.23-rc4-mm1 kernel with and without
| the following patches on a x86_64 defconfig (I also had to remove
| CONFIG_IPV6 for some compile reason) :
Thats a good point.
We have been a bit liberal with "inline"
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> >>
> >> +static struct net *get_net_ns_by_pid(pid_t pid)
> >> +{
> >> + struct task_struct *tsk;
> >> + struct net *net;
> >> +
> >> + /* Lookup the network namespace */
> >> + net = ERR_PTR(-ESRCH
Hi Balbir/Pavel,
As I mentioned to you directly at the kernel summit, I think it might
be cleaner to integrate resource counters more closely with control
groups. So rather than controllers such as the memory controller
having to create their own boilerplate cf_type structures and
read/write funct
On 9/7/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> Thanks for doing this. We are building containerstats for
> per container statistics. It would be really nice to provide
> the statistics using that interface. I am not opposed to
> memory.stat, but Paul Menage recommends that one file has
> ju
On 10/09/2007, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 10, 2007 at 10:22:59AM -0700, Andrew Morton wrote:
> > objection ;) "cpuctlr" isn't memorable. Kernel code is write-rarely,
> > read-often. "cpu_controller", please. The extra typing is worth it ;)
>
> Ok! Here's the mod
On 9/10/07, Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
> On 10/09/2007, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> > On Mon, Sep 10, 2007 at 10:22:59AM -0700, Andrew Morton wrote:
> > > objection ;) "cpuctlr" isn't memorable. Kernel code is write-rarely,
> > > read-often. "cpu_controller",
On 10/09/2007, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 10, 2007 at 10:22:59AM -0700, Andrew Morton wrote:
> > objection ;) "cpuctlr" isn't memorable. Kernel code is write-rarely,
> > read-often. "cpu_controller", please. The extra typing is worth it ;)
>
> Ok! Here's the mod
On 8/31/07, Paul Menage <[EMAIL PROTECTED]> wrote:
>
> I have a fix for this that I'm testing and should be able to send out soon.
>
Sorry for the delay on this - I was away all last week at the kernel
summit. I've sent out a patch to the list and to andrew, as a separate
thread.
Paul
___
Fix a reference counting bug in containerfs
As part of the extraction of cpusetfs to containerfs, a call to
cpuset_get_dentry() was lost (justified by the fact that the dentry in
question was now being passed down by the caller). Since
cpuset_get_dentry() called lookup_one_len(), this resulted in
FYI,
I just did a compile test on a 2.6.23-rc4-mm1 kernel with and without
the following patches on a x86_64 defconfig (I also had to remove
CONFIG_IPV6 for some compile reason) :
+ pid-namespaces-rework-forget_original_parent.patch
+ pid-namespaces-move-exit_task_namespaces.patch
+ pid-namesp
Quoting Paul Menage ([EMAIL PROTECTED]):
> On 9/4/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
> > We could of course have the ns_container subsystem do that. The
> > ns_container generally stick around until the admin does a manual rm on
> > its directory, so this way we could keep the nsproxy
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
>>
>> +static struct net *get_net_ns_by_pid(pid_t pid)
>> +{
>> +struct task_struct *tsk;
>> +struct net *net;
>> +
>> +/* Lookup the network namespace */
>> +net = ERR_PTR(-ESRCH);
>> +rcu_read_lock();
>> +tsk = find_task_by_pi
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
>
> The simplest thing to implement is moving network devices between
> namespaces. However with the same attribute IFLA_NET_NS_PID we can
> easily implement creating devices in the destination network
> namespace as well. However that is a little b
On 9/10/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
>
> Unless folks have strong objection to it, I prefer "cptctlr", the way it is.
>
By definition any container (about to be renamed control group)
subsystem is some kind of "controller" so that bit seems a bit
redundant.
Any reason not to
On 9/10/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
>
> Perhaps the biggest upside of this approach is that it's providing
> network functionality in a way that should be much more familiar to
> network folks. As opposed to using an lsm with a new vfs interface.
Right - one of the things that
Quoting Paul Menage ([EMAIL PROTECTED]):
> On 9/10/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
> >
> > The only downside I see right now is what to do about a sendto() on a
> > udp socket that hasn't been bound.
>
> Maybe have additional chains in the new iptable called "sendto" and
> "recvfrom
On 9/10/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
>
> The only downside I see right now is what to do about a sendto() on a
> udp socket that hasn't been bound.
Maybe have additional chains in the new iptable called "sendto" and
"recvfrom" that are invoked for those operations on unbound data
On Sep 10 2007 22:58, Srivatsa Vaddagiri wrote:
>On Mon, Sep 10, 2007 at 10:53:34PM +0530, Srivatsa Vaddagiri wrote:
>> > cpuctl, cpuctrl, cpu_controller?
>>
>> *shrug* .. I used "cpuctlr" to mean "CPU Controller". Any other short names
>> would do. From your list, cpuctl or cpuctrl both qualifie
On Sep 10 2007 10:22, Andrew Morton wrote:
>> Unless folks have strong objection to it, I prefer "cptctlr", the way it is.
>
>Kernel code is write-rarely, read-often.
I think you mean __read_mostly. :-)
Jan
--
___
Containers mailing list
[E
On Mon, Sep 10, 2007 at 10:22:59AM -0700, Andrew Morton wrote:
> objection ;) "cpuctlr" isn't memorable. Kernel code is write-rarely,
> read-often. "cpu_controller", please. The extra typing is worth it ;)
Ok! Here's the modified patch (against 2.6.23-rc4-mm1).
Signed-off-by : Srivatsa Vaddag
On Mon, Sep 10, 2007 at 10:53:34PM +0530, Srivatsa Vaddagiri wrote:
> > cpuctl, cpuctrl, cpu_controller?
>
> *shrug* .. I used "cpuctlr" to mean "CPU Controller". Any other short names
> would do. From your list, cpuctl or cpuctrl both qualifies IMO!
>
> Unless folks have strong objection to it,
On Mon, 10 Sep 2007 22:53:34 +0530 Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 10, 2007 at 07:05:00PM +0200, Jan Engelhardt wrote:
> > On Sep 10 2007 22:40, Srivatsa Vaddagiri wrote:
> > >+#ifdef CONFIG_FAIR_GROUP_SCHED
> > >+SUBSYS(cpuctlr)
> > >+#endif
> >
> > cpuctl, cpuctrl, c
On Mon, Sep 10, 2007 at 07:05:00PM +0200, Jan Engelhardt wrote:
> On Sep 10 2007 22:40, Srivatsa Vaddagiri wrote:
> >+#ifdef CONFIG_FAIR_GROUP_SCHED
> >+SUBSYS(cpuctlr)
> >+#endif
>
> cpuctl, cpuctrl, cpu_controller?
*shrug* .. I used "cpuctlr" to mean "CPU Controller". Any other short names
woul
On Sep 10 2007 22:40, Srivatsa Vaddagiri wrote:
>+#ifdef CONFIG_FAIR_GROUP_SCHED
>+SUBSYS(cpuctlr)
>+#endif
cpuctl, cpuctrl, cpu_controller?
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers
__
Ingo and Andrew,
The cfs core has been enhanced since quite sometime now to
understand task-groups and provide fairness to such task-group. What was
needed is an interface for the administrator to define task-groups and
specify group "importance" in terms of its cpu share.
The patch below
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> Sorry, I was focusing on the virtual server needs.
>
> devpts is it's own fs so I was fully expecting to make it mountable
> multiple times so a container can have it's own /dev/pts/0. So what
> other virtual devices would we want to be able to rec-
Quoting Daniel Lezcano ([EMAIL PROTECTED]):
> Serge E. Hallyn wrote:
>> Quoting Daniel Lezcano ([EMAIL PROTECTED]):
>>> Serge E. Hallyn wrote:
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
> From: Daniel Lezcano <[EMAIL PROTECTED]>
>
> For the moment, I only made this patch for th
Pavel Emelyanov <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>
> [snip]
>
>> --- /dev/null
>> +++ b/include/net/net_namespace.h
>> @@ -0,0 +1,68 @@
>> +/*
>> + * Operations on the network namespace
>> + */
>> +#ifndef __NET_NET_NAMESPACE_H
>> +#define __NET_NET_NAMESPACE_H
>> +
>> +#incl
Quoting Herbert Poetzl ([EMAIL PROTECTED]):
> On Thu, Sep 06, 2007 at 01:26:11PM -0500, Serge E. Hallyn wrote:
> > Quoting Herbert Poetzl ([EMAIL PROTECTED]):
> > > On Thu, Sep 06, 2007 at 11:55:34AM -0500, Serge E. Hallyn wrote:
> > > > Roadmap is a bit of an exaggeration, but here is a list of th
Eric W. Biederman wrote on 09/09/2007 02:45:34 AM:
Hi Eric,
> +static int register_pernet_operations(struct list_head *list,
> + struct pernet_operations *ops)
> +{
>
> +out:
> + return error;
> +
> +out_undo:
> + /* If I have an error cleanup all namespaces I initialized */
Quoting Serge E. Hallyn ([EMAIL PROTECTED]):
> Quoting Herbert Poetzl ([EMAIL PROTECTED]):
> > > For instance CAP_IPC_LOCK doesn't really matter for
> > > CAP_HOST_ADMIN since the namespaces prevent you cross-ns
> > > access.
> >
> > hmm? maybe I am misunderstanding the entire concept
> > of CA
On Thu, Sep 06, 2007 at 01:26:11PM -0500, Serge E. Hallyn wrote:
> Quoting Herbert Poetzl ([EMAIL PROTECTED]):
> > On Thu, Sep 06, 2007 at 11:55:34AM -0500, Serge E. Hallyn wrote:
> > > Roadmap is a bit of an exaggeration, but here is a list of the
> > > next bit of work i expect to do relating to
Takashi is AFK for a while; i'm replying for him as possible.
> Thanks for doing this. We are building containerstats for
> per container statistics. It would be really nice to provide
> the statistics using that interface. I am not opposed to
> memory.stat, but Paul Menage recommends that one fi
Roadmap is a bit of an exaggeration, but here is a list of the next bit
of work i expect to do relating to containers and access control. The
list gets more vague toward the end, with the intent of going far enough
ahead to show what the final result would hopefully look like.
Please review and t
Quoting Herbert Poetzl ([EMAIL PROTECTED]):
> On Thu, Sep 06, 2007 at 11:55:34AM -0500, Serge E. Hallyn wrote:
> > Roadmap is a bit of an exaggeration, but here is a list of the next bit
> > of work i expect to do relating to containers and access control. The
> > list gets more vague toward the e
On Thu, Sep 06, 2007 at 11:55:34AM -0500, Serge E. Hallyn wrote:
> Roadmap is a bit of an exaggeration, but here is a list of the next bit
> of work i expect to do relating to containers and access control. The
> list gets more vague toward the end, with the intent of going far enough
> ahead to s
>> * Console
>>
>> . a running getty should be covered by tty namespace
to log onto a container, we could simply run a getty in the
guest with the guest end of the tty in a pts namespace.
C.
___
Containers mailing list
[EMAIL PROTECTED]
https://li
Cedric Le Goater wrote:
> Held at De Vere Universty Arms Hotel, Cambridge, UK
>
> * Monday, Sept 3, 9h00 to 16h00 :
>
> Kir Kolyshkin <[EMAIL PROTECTED]>
> Pavel Emelianov <[EMAIL PROTECTED]>
> Masahiko Takahashi <[EMAIL PROTECTED]>
> Oren Laadan <[EMAIL PROTECTED]>
>
Quoting Cedric Le Goater ([EMAIL PROTECTED]):
...
> Container mini-summit notes v0.01
>
> ==
>
> Held at Universty Arm's, Cambridge, UK
>
> on 3rd of September, 9h00 to 16h00 :
>
> Kir Kolyshkin <[EMAIL PROTECTED]>
>
Cedric Le Goater wrote:
Held at De Vere Universty Arms Hotel, Cambridge, UK
* Monday, Sept 3, 9h00 to 16h00 :
Kir Kolyshkin <[EMAIL PROTECTED]>
Pavel Emelianov <[EMAIL PROTECTED]>
Masahiko Takahashi <[EMAIL PROTECTED]>
Oren Laadan <[EMAIL PROTECTED]>
James Youngman <[EMAIL
>>. kthread cleanup
>> replace kernel_thread() by the kthread API
>> change core kthread API to support signals
no one on that task.
I'm pretty sure hch would be happy to help someone on it.
>> nfs needs extra love. is someone working on it ?
>
> REALLY wou
Held at De Vere Universty Arms Hotel, Cambridge, UK
* Monday, Sept 3, 9h00 to 16h00 :
Kir Kolyshkin <[EMAIL PROTECTED]>
Pavel Emelianov <[EMAIL PROTECTED]>
Masahiko Takahashi <[EMAIL PROTECTED]>
Oren Laadan <[EMAIL PROTECTED]>
James Youngman <[EMAIL PROTE
Pavel Emelyanov <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Until we support multiple network namespaces with netfilter only allow
>> netfilter configuration in the initial network namespace.
>
> PATCH 17/16? :)
Exactly!
If my target was the core of the networking stack I figured I
Pavel Emelyanov <[EMAIL PROTECTED]> writes:
>
> Rr. This is the 5th or even the 6th patch that changes tens of files
> but (!) most of these changes are just propagating some core thing into
> protocols, drivers, etc. E.g. you add an argument to some function and
> then make all the rest use it
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
>
> >> > then you should have taken CAP_SYS_MKNOD away from the container.
> >>
> >> no serge,
> >>
> >> we want the container to be able to mknod()
> >
> > Someone give me one good reason why this is
The inode->i_flock list contains the leases, flocks and posix
locks in the specified order. However, the flocks are added in
the head of this list thus hiding the leases from F_GETLEASE
command, from time_out_leases() and other code that expects
the leases to come first.
The following example will
Serge E. Hallyn wrote:
Quoting Daniel Lezcano ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
From: Daniel Lezcano <[EMAIL PROTECTED]>
For the moment, I only made this patch for the RFC. It shows how simple
it is
to hook different socket syscalls. T
Eric W. Biederman wrote:
> Until we support multiple network namespaces with netfilter only allow
> netfilter configuration in the initial network namespace.
PATCH 17/16? :)
Sorry,
Pavel
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-
Eric W. Biederman wrote:
> Each netlink socket will live in exactly one network namespace,
> this includes the controlling kernel sockets.
>
> This patch updates all of the existing netlink protocols
> to only support the initial network namespace. Request
> by clients in other namespaces will ge
Quoting Daniel Lezcano ([EMAIL PROTECTED]):
> Serge E. Hallyn wrote:
>> Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
>>> From: Daniel Lezcano <[EMAIL PROTECTED]>
>>>
>>> For the moment, I only made this patch for the RFC. It shows how simple
>>> it is
>>> to hook different socket syscalls. This
Eric W. Biederman wrote:
[snip]
> --- /dev/null
> +++ b/include/net/net_namespace.h
> @@ -0,0 +1,68 @@
> +/*
> + * Operations on the network namespace
> + */
> +#ifndef __NET_NET_NAMESPACE_H
> +#define __NET_NET_NAMESPACE_H
> +
> +#include
> +#include
> +#include
> +
> +struct net {
Isn't thi
箕浦真 wrote:
> Takashi is AFK for a while; i'm replying for him as possible.
>
>> Thanks for doing this. We are building containerstats for
>> per container statistics. It would be really nice to provide
>> the statistics using that interface. I am not opposed to
>> memory.stat, but Paul Menage reco
[EMAIL PROTECTED] wrote:
> Pavel,
>
> I noticed that fcntl tests in LTP fail when LTP is run a child pid
> namespace. I just hacked up this quick patch and seems to fix the
> failures.
>
> Are you already working on this or do you want me to test and send
> this out for review.
>
> I have one c
59 matches
Mail list logo
