Sukadev Bhattiprolu wrote:
Patch 5/7 is new in this set and fixes a bug. Remaining patches are
just a forward-port from previous version and I believe they address
all comments I have received.
Oleg please sign-off/ack if you agree.
---
Container-init must behave like global-init to
suka...@linux.vnet.ibm.com wrote:
Enable multiple instances of devpts filesystem so each container can allocate
ptys independently.
Hi suka,
It looks like the /proc/sys/kernel/pty/max and nr are not virtualized.
Modifying in the container the max pty, that impacts the init_pty.
Same as nr
Sukadev Bhattiprolu suka...@linux.vnet.ibm.com writes:
From: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
Date: Wed, 24 Dec 2008 14:14:18 -0800
Subject: [PATCH 7/7][v8] SI_USER: Masquerade si_pid when crossing pid ns
boundary
When sending a signal to a descendant namespace, set -si_pid to
Daniel Lezcano wrote:
suka...@linux.vnet.ibm.com wrote:
Enable multiple instances of devpts filesystem so each container can
allocate
ptys independently.
Hi suka,
It looks like the /proc/sys/kernel/pty/max and nr are not virtualized.
Modifying in the container the max pty, that
H. Peter Anvin wrote:
Daniel Lezcano wrote:
suka...@linux.vnet.ibm.com wrote:
Enable multiple instances of devpts filesystem so each container can
allocate
ptys independently.
Hi suka,
It looks like the /proc/sys/kernel/pty/max and nr are not virtualized.
Modifying
Use the new checkpoint/restart file functions to query
and report on each fd in the /proc/$$/fdinfo/X file.
This should provide an easy way to examine processes
at runtime to see what exactly is causing their inability
to checkpoint.
Signed-off-by: Dave Hansen d...@linux.vnet.ibm.com
---
I'll be adding to this in a moment and it is in a bad place
to do that cleanly now.
Also, increase the buffer size. Most /proc files can
output up to a page, so use the same here.
Signed-off-by: Dave Hansen d...@linux.vnet.ibm.com
---
linux-2.6.git-dave/fs/proc/base.c | 23
This pair of functions will check to see whether a given
'struct file' can be checkpointed. If it can't be, the
explain function can also give a description why.
Signed-off-by: Dave Hansen d...@linux.vnet.ibm.com
---
linux-2.6.git-dave/checkpoint/ckpt_file.c | 30
Introduce a files_struct counter to indicate whether a particular
file_struct has ever contained a file which can not be
checkpointed. This flag is a one-way trip; once it is set, it may
not be unset.
We assume at allocation that a new files_struct is clean and may
be checkpointed. However, as
There are plenty of filesystems that are not supported for
c/r at this point. Think of things like hugetlbfs which
are externally visible or pipefs which are kernel-internal.
This provides a quick way to make the normal filesystems
which are currently supported. This is also safe if any
new
BTW, after you apply this and turn on the config option, you do get a
ton of warnings at runtime.
qemu:~# cat /proc/*/fdinfo/* | grep check | sort | uniq -c | sort -n
1 checkpointable: 0(proc does not support checkpoint)
6 checkpointable: 0(pipefs does not support checkpoint)
On 02/19, Eric W. Biederman wrote:
Sukadev Bhattiprolu suka...@linux.vnet.ibm.com writes:
From: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
Date: Wed, 24 Dec 2008 14:14:18 -0800
Subject: [PATCH 7/7][v8] SI_USER: Masquerade si_pid when crossing pid ns
boundary
When sending a
I think that all these efforts to abort checkpoint intelligently by
banning it early are completely misguided.
Checkpointable property isn't one-way ticket like tainted flag,
so doing it like tainted var isn't right, atomic or not, SMP-safe or
not.
With filesystems, one has -f_op field to
On Thu, Feb 19, 2009 at 10:20:07AM -0800, Dave Hansen wrote:
There are plenty of filesystems that are not supported for
c/r at this point. Think of things like hugetlbfs which
are externally visible or pipefs which are kernel-internal.
This provides a quick way to make the normal
On Thu, 2009-02-19 at 22:06 +0300, Alexey Dobriyan wrote:
Inotify isn't supported yet? You do
if (!list_empty(inode-inotify_watches))
return -E;
without hooking into inotify syscalls.
ptrace(2) isn't supported -- look at struct task_struct::ptraced and
friends.
On Thu, 2009-02-19 at 14:00 -0500, Christoph Hellwig wrote:
On Thu, Feb 19, 2009 at 10:20:07AM -0800, Dave Hansen wrote:
There are plenty of filesystems that are not supported for
c/r at this point. Think of things like hugetlbfs which
are externally visible or pipefs which are
Daniel Lezcano wrote:
Resource limit partitioning is a much bigger and orthogonal problem.
In this case we don't have the pty allocated independently, no ?
I mean one container can allocate 4095 pty, making a pty starvation for
others containers. Or imagine I am a vilain and I want to
Oleg Nesterov [o...@redhat.com] wrote:
| On 02/18, Sukadev Bhattiprolu wrote:
|
| read_lock(tasklist_lock);
| nr = next_pidmap(pid_ns, 1);
| while (nr 0) {
| - kill_proc_info(SIGKILL, SEND_SIG_PRIV, nr);
| + rcu_read_lock();
| +
| + /*
| +
On 02/18, Sukadev Bhattiprolu wrote:
Patch 5/7 is new in this set and fixes a bug.
To clarify, the current code is buggy, and the fix doesn't depend on
any other patch, afaics.
Remaining patches are
just a forward-port from previous version and I believe they address
all comments I have
Oleg Nesterov o...@redhat.com writes:
On 02/19, Eric W. Biederman wrote:
Sukadev Bhattiprolu suka...@linux.vnet.ibm.com writes:
From: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
Date: Wed, 24 Dec 2008 14:14:18 -0800
Subject: [PATCH 7/7][v8] SI_USER: Masquerade si_pid when crossing
H. Peter Anvin h...@zytor.com writes:
Daniel Lezcano wrote:
Resource limit partitioning is a much bigger and orthogonal problem.
In this case we don't have the pty allocated independently, no ?
I mean one container can allocate 4095 pty, making a pty starvation for
others
containers.
On 02/19, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
SI_FROMUSER() == T, unless we have more (hopefully not) in-kernel
users which send SI_FROMUSER() signals, .si_pid must be valid?
So the argument is that while things such as force_sig_info(SIGSEGV)
don't have a
H. Peter Anvin wrote:
Daniel Lezcano wrote:
Resource limit partitioning is a much bigger and orthogonal problem.
In this case we don't have the pty allocated independently, no ?
I mean one container can allocate 4095 pty, making a pty starvation
for others containers. Or imagine I am a
Oleg Nesterov o...@redhat.com writes:
On 02/19, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
SI_FROMUSER() == T, unless we have more (hopefully not) in-kernel
users which send SI_FROMUSER() signals, .si_pid must be valid?
So the argument is that while things such as
Suppose I have 3 processes in a process group in three separate pid
namespaces.
Looking from the init pid namespace I have:
pid pgrp ppid
10 101
11 1010
12 1011
Looking from the pid namespace of pid 11 I have:
pid pgrp ppid
0 0 0
Daniel Lezcano daniel.lezc...@free.fr writes:
But if I am able to create a new instance of devpts for a container and modify
the configuration of another devpts from this container, is it acceptable ?
Can
we convince people to use the containers for security and have anybody able to
make a
On 02/19, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
On 02/19, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
SI_FROMUSER() == T, unless we have more (hopefully not) in-kernel
users which send SI_FROMUSER() signals, .si_pid must be valid?
Roland McGrath rol...@redhat.com writes:
Suppose I have 3 processes in a process group in three separate pid
namespaces.
Looking from the init pid namespace I have:
pid pgrp ppid
10 101
11 1010
12 1011
Looking from the pid namespace of pid 11 I have:
It is especially useful, and this is a deliberate feature.
Ok, I thought that might be so.
In practice I don't care about si_pid and I doubt I care about processes
sending signals outside of their pid namespace. But I do care about
sharing a tty and a session and having job control work.
Roland McGrath rol...@redhat.com writes:
It is especially useful, and this is a deliberate feature.
Ok, I thought that might be so.
In practice I don't care about si_pid and I doubt I care about processes
sending signals outside of their pid namespace. But I do care about
sharing a tty
think it would be best to fully elucidate what we think about desireable
semantics for the whole spectrum of cross-NS signal-sending cases before
actually choosing the implementation details.
... and then you answered all the questions that are already well settled,
and did not address the
Roland McGrath rol...@redhat.com writes:
think it would be best to fully elucidate what we think about desireable
semantics for the whole spectrum of cross-NS signal-sending cases before
actually choosing the implementation details.
... and then you answered all the questions that are
Oleg Nesterov o...@redhat.com writes:
On 02/19, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
On 02/19, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
SI_FROMUSER() == T, unless we have more (hopefully not) in-kernel
users which send
Eric W. Biederman wrote:
Really. You have the same classes of issues with ANY allocatable
resource in the system. Period. Furthermore, there are quite a few
applications which want one and not the other. Trying to entangle
them is broken.
Peter they are entangled issues because the
34 matches
Mail list logo
