Serge E. Hallyn wrote:
> Quoting Pavel Emelianov ([EMAIL PROTECTED]):
>> This includes #ifdefs in get/put_pid_ns and rewriting
>> the child_reaper() function to the more logical view.
>>
>> This doesn't fit logically into any other patch so
>> I decided to make it separate.
>>
>> Signed-off-by: Pav
[EMAIL PROTECTED] wrote:
> Subject: Move alloc_pid call to copy_process
>
> From: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
>
> Move alloc_pid() into copy_process(). This will keep all pid and pid
> namespace code together and simplify error handling when we support
> multiple pid namespaces.
I ha
Dave Hansen wrote:
> On Thu, 2007-05-24 at 13:24 +0400, Pavel Emelianov wrote:
>>> | > +int is_global_init(struct task_struct *tsk)
>>> | > +{
>>> | > + return (task_active_pid_ns(tsk) == &init_pid_ns && tsk->pid == 1);
>>> |
>>> | This can OOPS if you pass arbitrary task to this call...
>>> | tsk
Eric W. Biederman wrote:
> Pavel Emelianov <[EMAIL PROTECTED]> writes:
>
>> That's true. Sending of signal from parent ns to children
>> is tricky question. It has many solutions, I wanted to
>> discuss which one is better:
>
> With unix domain sockets and the like it is conceivable we get
> a pi
Serge E. Hallyn wrote:
> Quoting Eric W. Biederman ([EMAIL PROTECTED]):
>> Pavel Emelianov <[EMAIL PROTECTED]> writes:
>>
>>> That's how OpenVZ sees the pid namespaces.
>>>
>>> The main idea is that kernel keeps operating with tasks pid
>>> as it did before, but each task obtains one more pid for e
From: Vasily Averin <[EMAIL PROTECTED]>
Date: Thu, 24 May 2007 09:23:14 +0400
> sys_setsockopt() do not check properly timeout values for
> SO_RCVTIMEO/SO_SNDTIMEO, for example it's possible to set negative timeout
> values. POSIX do not defines behaviour for sys_setsockopt in case negative
> time
Pavel Emelianov <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Pavel Emelianov <[EMAIL PROTECTED]> writes:
>>
>>> That's how OpenVZ sees the pid namespaces.
>>>
>>> The main idea is that kernel keeps operating with tasks pid
>>> as it did before, but each task obtains one more pid for
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
>
> >> 3. Cleaner logic for namespace migration: with this approach
> >>one need to save the virtual pid and let global one change;
> >>with Suka's logic this is not clear how to migrate the leve
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
>> 3. Cleaner logic for namespace migration: with this approach
>>one need to save the virtual pid and let global one change;
>>with Suka's logic this is not clear how to migrate the level
>>2 namespace (concerning init to be level 0).
>
>
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
> Serge E. Hallyn wrote:
> > Quoting Pavel Emelianov ([EMAIL PROTECTED]):
> >> That's how OpenVZ sees the pid namespaces.
> >>
> >> The main idea is that kernel keeps operating with tasks pid
> >> as it did before, but each task obtains one more pid for
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
>
> > Quoting Pavel Emelianov ([EMAIL PROTECTED]):
> >> The set of functions process_session, task_session, process_group
> >> and task_pgrp is confusing, as the names can be mixed with each other
> >> w
On Thu, 2007-05-24 at 16:50 +0400, Pavel Emelianov wrote:
>
> +struct pid * fastcall __find_vpid(int nr, struct pid_namespace *ns)
> +{
> +#ifdef CONFIG_PID_NS
> + struct hlist_node *elem;
> + struct pid *pid;
> +#endif
> +
> + if (ns == &init_pid_ns)
> + return fin
On Thu, May 24, 2007 at 12:26:16AM +0200, Guillaume Chazarain wrote:
> As a sidenote, while in CFS-v13 a nice=0 tasks seems to get 10x more CPU
> than a nice=10 one, with the group fairness patch, the ratio drops to
> less than 2x (for tasks with the same UID).
Thanks for reporting this regressi
On Thu, 2007-05-24 at 14:15 +0400, Pavel Emelianov wrote:
>
> > s->s_flags |= MS_NODIRATIME | MS_NOSUID | MS_NOEXEC;
> > @@ -466,6 +467,7 @@ int proc_fill_super(struct super_block *
> > s->s_magic = PROC_SUPER_MAGIC;
> > s->s_op = &proc_sops;
> > s->s_time_gran = 1;
> > +
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
> This includes #ifdefs in get/put_pid_ns and rewriting
> the child_reaper() function to the more logical view.
>
> This doesn't fit logically into any other patch so
> I decided to make it separate.
>
> Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED
Pavel Emelianov wrote:
Eric W. Biederman wrote:
Pavel Emelianov <[EMAIL PROTECTED]> writes:
That's how OpenVZ sees the pid namespaces.
The main idea is that kernel keeps operating with tasks pid
as it did before, but each task obtains one more pid for each
pid type - the virtual pid.
On Thu, 2007-05-24 at 13:24 +0400, Pavel Emelianov wrote:
> > | > +int is_global_init(struct task_struct *tsk)
> > | > +{
> > | > + return (task_active_pid_ns(tsk) == &init_pid_ns && tsk->pid == 1);
> > |
> > | This can OOPS if you pass arbitrary task to this call...
> > | tsk->nsproxy can already
Pavel Emelianov <[EMAIL PROTECTED]> writes:
> That's true. Sending of signal from parent ns to children
> is tricky question. It has many solutions, I wanted to
> discuss which one is better:
With unix domain sockets and the like it is conceivable we get
a pid transfer from one namespace to anoth
Eric W. Biederman wrote:
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
>
>> Quoting Pavel Emelianov ([EMAIL PROTECTED]):
>>> The set of functions process_session, task_session, process_group
>>> and task_pgrp is confusing, as the names can be mixed with each other
>>> when looking at the code fo
Eric W. Biederman wrote:
> Pavel Emelianov <[EMAIL PROTECTED]> writes:
>
>> That's how OpenVZ sees the pid namespaces.
>>
>> The main idea is that kernel keeps operating with tasks pid
>> as it did before, but each task obtains one more pid for each
>> pid type - the virtual pid. When putting the
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> Quoting Pavel Emelianov ([EMAIL PROTECTED]):
>> The set of functions process_session, task_session, process_group
>> and task_pgrp is confusing, as the names can be mixed with each other
>> when looking at the code for a long time.
>>
>> The proposa
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
> The set of functions process_session, task_session, process_group
> and task_pgrp is confusing, as the names can be mixed with each other
> when looking at the code for a long time.
>
> The proposals are to
> * equip the functions that return the inte
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> Pavel Emelianov <[EMAIL PROTECTED]> writes:
>
> > That's how OpenVZ sees the pid namespaces.
> >
> > The main idea is that kernel keeps operating with tasks pid
> > as it did before, but each task obtains one more pid for each
> > pid type - the vir
Cedric Le Goater wrote:
> Hello Pavel !
>
> I'm giving it a try.
If you want, I can give you complete instructions
of how to do it. When I started to test it I faced
many tricky places and just want to make sure you
won't spent time solving the problems I solved.
> For those using qemu, you'll n
Eric W. Biederman wrote:
> Pavel Emelianov <[EMAIL PROTECTED]> writes:
>
>> This is the largest patch in the set. Make all (I hope)
>> the places where the pid is shown to or get from user
>> operate on the virtual pids.
>>
>> An exception is copy_process - it was in one of the
>> previous patche
On 5/24/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
I thought about this approach, but did not implement the code this way
because a system could have thousands of containers and expecting a
statistics application to open a file descriptor each time for each
container will turn out to be an expe
Serge E. Hallyn wrote:
> Quoting Pavel Emelianov ([EMAIL PROTECTED]):
>> That's how OpenVZ sees the pid namespaces.
>>
>> The main idea is that kernel keeps operating with tasks pid
>> as it did before, but each task obtains one more pid for each
>> pid type - the virtual pid. When putting the pid
Pavel Emelianov <[EMAIL PROTECTED]> writes:
> This is the largest patch in the set. Make all (I hope)
> the places where the pid is shown to or get from user
> operate on the virtual pids.
>
> An exception is copy_process - it was in one of the
> previous patches - and the proc - this will come a
Pavel Emelianov <[EMAIL PROTECTED]> writes:
> That's how OpenVZ sees the pid namespaces.
>
> The main idea is that kernel keeps operating with tasks pid
> as it did before, but each task obtains one more pid for each
> pid type - the virtual pid. When putting the pid to user or
> getting the pid f
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
>
> Subject: Enable signaling child reaper from parent ns.
>
> From: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
>
> The reaper of a child namespace must receive signals from its parent pid
> namespace but not receive any signals from its own namespace.
Paul Menage wrote:
> Hi Balbir,
>
> On 5/14/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>>
>> This patch implements per container statistics infrastructure and re-uses
>> code from the taskstats interface. A new set of container operations are
>> registered with commands and attributes. It should
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
> That's how OpenVZ sees the pid namespaces.
>
> The main idea is that kernel keeps operating with tasks pid
> as it did before, but each task obtains one more pid for each
> pid type - the virtual pid. When putting the pid to user or
> getting the pid
Pavel Emelianov <[EMAIL PROTECTED]> writes:
>
> diff --git a/init/Kconfig b/init/Kconfig
> index 2a46e35..59e4625 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -127,6 +127,16 @@ config SWAP_PREFETCH
> Workstations and multiuser workstation servers will most likely want
> to
yes, thanks.
I commited this:
http://git.openvz.org/?p=linux-2.6.18-openvz;a=commitdiff;h=a2eac3fd8bae65547195479e919b84e06ddd54f3
And Kir commited vzctl fix for configure.ac
Thanks for your reports,
Kirill
Christian Kaiser2 wrote:
> Hi all,
>
> here is first one fix for the current 2.6.18-ope
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
>
> Subject: Define is_global_init()
>
> From: Serge E. Hallyn <[EMAIL PROTECTED]>
>
>
> is_init() is an ambiguous name for the pid==1 check. Split it into
> is_global_init() and is_container_init().
>
> A container init has it's tsk->pid == 1.
>
Hi all,
here is first one fix for the current 2.6.18-openvz kernel:
diff --git a/include/asm-powerpc/current.h b/include/asm-powerpc/current.h
index b8708ae..e78c677 100644
--- a/include/asm-powerpc/current.h
+++ b/include/asm-powerpc/current.h
@@ -13,6 +13,7 @@ struct task_struct;
#ifdef __po
Can you check the value of __NR_fairsched_chwt in vzctl? It is defined
in include/vzsyscalls.h depending on your architecture. For ppc it
should be 402 (same as in kernel's include/asm-powerpc/unistd.h). In
case these numbers are different things will go wrong.
You can easily check it the numb
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
>
> Subject: Enable cloning pid namespace
>
> From: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
>
>
> When clone() is invoked with CLONE_NEWPID, create a new pid namespace
> and then create a new struct pid for the new process. Allocate pid_t's
> for t
Hi all,
as I mentioned already yesterday I get this error when I try to start the
OpenVZ service:
[EMAIL PROTECTED] ~]# /etc/init.d/vz start
Starting OpenVZ: [ OK ]
Bringing up interface venet0: [ OK ]
Configuring interfa
That's the program I used for testing. It creates a new
session, chroots to new root, clones the namespace, mounts
proc and launches the sshd to keep track of the terminals.
The new root I prepared was bind-mounted /lib, /bin, /usr
etc directories, copied /dev devices with devpts mounted
inside
This is a hack that must not go to any tree, but this
makes patch testing from shell possible.
When creating a new pid namespace one need to mount a new
proc instance in this space context. But the /proc will
contain pids and self symlink only and this breaks some
important tools like ps and ssh
This is the proc-related part of the previous patch.
Since tasks are seen from two proc-s the appropriate
(virtual or global) pid must be shown.
Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
---
diff --git a/fs/proc/array.c b/fs/proc/array.c
index aef7b7b..f65e4c9 100644
--- a/fs/proc/array
This is the largest patch in the set. Make all (I hope)
the places where the pid is shown to or get from user
operate on the virtual pids.
An exception is copy_process - it was in one of the
previous patches - and the proc - this will come as a
separate patch.
Signed-off-by: Pavel Emelianov <[E
The design is the following. The pids shown in proc tree are
the ones get from the namespace the superblock belongs to.
As seen from the previous patch, when proc is mounted the
current namespace is considered to be the owner of the superbloc.
Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]/.o
Each namespace must have its own proc super block where
dentries and inodes representing the tasks live.
Plus proc super block bust hold the namespace it draws
the pids from.
Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
---
diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h
in
This is the core of the set - the namespace cloning.
The cloning consists of two stages - creating of the new
namespace and moving a task into it. Create and move is
not good as the error path just puts the new namespaces
and thus keep the task in it.
So after the new namespace is clones task st
When new task is created it must have its virtual pids set.
When task belongs to init namespace the pids are equal to
global ones so it is safe to get vpid from any task.
This is the place where we export pids to use space and there
will be a patch for these cases, but this case is specal and
thu
This patch make alloc_pid() and free_pid() aware of the
namespaces. When a pid is created not in init namespace
it gets into two hashes and holds the pointer to the
namespace itself.
Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
---
diff --git a/kernel/pid.c b/kernel/pid.c
index eb66bd2..1
We need the extended set of functions for searching
tasks and pids - search in global namespace, in local
namespace (current belongs to) and in arbitrary namespace
(used in proc).
Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
---
diff --git a/include/linux/sched.h b/include/linux/sched.h
in
Since we want to export virtual pid to userspace and this is
optional (CONFIG_PID_NS) we need helpers for getting the values
of vpid/vtgid/etc depending on the config and the appropriate
members on structs.
A note about the struct pid. As will be seen later pid may now
be stored in two hashes - pi
The config option is CONFIG_PID_NS. The flag is CLONE_NEWPIDS.
As I have already said - cloning of pid namespace from fork()
is not allowed - use unshare for this.
Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
---
diff --git a/init/Kconfig b/init/Kconfig
index 2a46e35..59e4625 100644
--- a
This includes #ifdefs in get/put_pid_ns and rewriting
the child_reaper() function to the more logical view.
This doesn't fit logically into any other patch so
I decided to make it separate.
Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
---
diff --git a/include/linux/pid_namespace.h b/inclu
The set of functions process_session, task_session, process_group
and task_pgrp is confusing, as the names can be mixed with each other
when looking at the code for a long time.
The proposals are to
* equip the functions that return the integer with _nr suffix to
represent that fact,
* and to ma
That's how OpenVZ sees the pid namespaces.
The main idea is that kernel keeps operating with tasks pid
as it did before, but each task obtains one more pid for each
pid type - the virtual pid. When putting the pid to user or
getting the pid from it kernel operates with the virtual ones.
E.g. virt
[EMAIL PROTECTED] wrote:
> Subject: Introduce proc_mnt for pid_ns
>
> From: Dave Hansen <[EMAIL PROTECTED]>
>
> The following patch completes the removal of the global proc_mnt.
> It fetches the mnt on which to do dentry invalidations from the
> pid_namespace in which the task appears.
>
> For n
On Wed, May 23, 2007 at 09:49:44AM -0500, Serge E. Hallyn wrote:
> Quoting Alexey Dobriyan ([EMAIL PROTECTED]):
> > I ran ltp-full-20070430 and utstest.c forgot to restore original
> > hostname from serge2. ;-)
>
> Oh that's just me taking over the world, one workstation at a time.
>
> Hopefully th
Pavel Emelianov [EMAIL PROTECTED] wrote:
| [EMAIL PROTECTED] wrote:
| > Pavel Emelianov [EMAIL PROTECTED] wrote:
| > | > Index: lx26-21-mm2/kernel/pid.c
| > | > ===
| > | > --- lx26-21-mm2.orig/kernel/pid.c 2007-05-22 16:59:46.00
Pavel Emelianov [EMAIL PROTECTED] wrote:
| > +/*
| > + * Return the pid_t by which the process @pid is known in the pid
| > + * namespace @ns.
| > + *
| > + * Return 0 if:
| > + * - @pid is NULL (eg: procfs calls this for task_pgrp(init_task)
| > + * which is NULL).
| > + *
| > +
I haven't found an appropriate patch, so I ask the
question here.
Consider we're sending a signal from parent namespace
to one of the child namespaces. What pid will be put
in siginfo as si_pid?
Pavel.
___
Containers mailing list
[EMAIL PROTECTED]
https
[EMAIL PROTECTED] wrote:
> Pavel Emelianov [EMAIL PROTECTED] wrote:
> | > Index: lx26-21-mm2/kernel/pid.c
> | > ===
> | > --- lx26-21-mm2.orig/kernel/pid.c 2007-05-22 16:59:46.0 -0700
> | > +++ lx26-21-mm2/kernel/pid.c 200
[EMAIL PROTECTED] wrote:
> Pavel Emelianov [EMAIL PROTECTED] wrote:
> | > Index: lx26-21-mm2/kernel/pid.c
> | > ===
> | > --- lx26-21-mm2.orig/kernel/pid.c 2007-05-22 16:59:34.0 -0700
> | > +++ lx26-21-mm2/kernel/pid.c 200
[EMAIL PROTECTED] wrote:
> Subject: Introduce proc_mnt for pid_ns
>
> From: Dave Hansen <[EMAIL PROTECTED]>
>
> The following patch completes the removal of the global proc_mnt.
> It fetches the mnt on which to do dentry invalidations from the
> pid_namespace in which the task appears.
>
> For n
Pavel Emelianov [EMAIL PROTECTED] wrote:
| > Index: lx26-21-mm2/kernel/pid.c
| > ===
| > --- lx26-21-mm2.orig/kernel/pid.c 2007-05-22 16:59:46.0 -0700
| > +++ lx26-21-mm2/kernel/pid.c2007-05-22 17:06:48.0 -070
Pavel Emelianov [EMAIL PROTECTED] wrote:
| > Index: lx26-21-mm2/kernel/pid.c
| > ===
| > --- lx26-21-mm2.orig/kernel/pid.c 2007-05-22 16:59:34.0 -0700
| > +++ lx26-21-mm2/kernel/pid.c2007-05-22 16:59:46.0 -070
> +/*
> + * Return the pid_t by which the process @pid is known in the pid
> + * namespace @ns.
> + *
> + * Return 0 if:
> + * - @pid is NULL (eg: procfs calls this for task_pgrp(init_task)
> + * which is NULL).
> + *
> + * - process does not have pid_t in the namespace @ns (eg: parent
> +
> Index: lx26-21-mm2/kernel/pid.c
> ===
> --- lx26-21-mm2.orig/kernel/pid.c 2007-05-22 16:59:46.0 -0700
> +++ lx26-21-mm2/kernel/pid.c 2007-05-22 17:06:48.0 -0700
> @@ -216,6 +216,10 @@ fastcall void free_pid(struc
> Index: lx26-21-mm2/kernel/pid.c
> ===
> --- lx26-21-mm2.orig/kernel/pid.c 2007-05-22 16:59:34.0 -0700
> +++ lx26-21-mm2/kernel/pid.c 2007-05-22 16:59:46.0 -0700
> @@ -71,6 +71,27 @@ struct pid_namespace init_pid_
> Index: lx26-21-mm2/kernel/pid.c
> ===
> --- lx26-21-mm2.orig/kernel/pid.c 2007-05-22 16:59:34.0 -0700
> +++ lx26-21-mm2/kernel/pid.c 2007-05-22 16:59:46.0 -0700
> @@ -71,6 +71,27 @@ struct pid_namespace init_pid_
> ===
> --- lx26-21-mm2.orig/kernel/timer.c 2007-05-22 16:58:38.0 -0700
> +++ lx26-21-mm2/kernel/timer.c2007-05-22 16:59:44.0 -0700
> @@ -945,7 +945,7 @@ asmlinkage long sys_getppid(void)
> int pid;
>
Pavel Emelianov wrote:
>> Index: linux-2.6.20/mm/rss_container.c
>> ===
>> --- linux-2.6.20.orig/mm/rss_container.c 2007-05-15 05:13:46.0
>> -0700
>> +++ linux-2.6.20/mm/rss_container.c 2007-05-16 20:45:45.0 -0700
Paul Menage wrote:
> On 5/24/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>> Kirill Korotaev wrote:
>> >> Where do we stand on all of this now anyway? I was thinking of
>> getting Paul's
>> >> changes into -mm soon, see what sort of calamities that brings about.
>> > I think we can merge Paul's pat
On 5/24/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
Kirill Korotaev wrote:
>> Where do we stand on all of this now anyway? I was thinking of getting
Paul's
>> changes into -mm soon, see what sort of calamities that brings about.
> I think we can merge Paul's patches with *interfaces* and then s
Kirill Korotaev wrote:
>> Where do we stand on all of this now anyway? I was thinking of getting
>> Paul's
>> changes into -mm soon, see what sort of calamities that brings about.
> I think we can merge Paul's patches with *interfaces* and then switch to
> developing/reviewing/commiting resource
73 matches
Mail list logo
