On Fri, 25 Jul 2008 04:14:55 -0400 Paul Menage [EMAIL PROTECTED] wrote:
Hi Balbir,
Andrew included the memrlimit controller in his latest set of patches
to Linus for mainline.
I've asked Linus to drop all 238 patches. I'll be resending them minus
the offending memrlimit patches.
Did I
On Fri, 25 Jul 2008, Paul Menage wrote:
So I think we'd be complicating some of the vm paths in mainline with
a feature that isn't likely to get a lot of real use.
What do you (and others on the containers list) think? Should we ask
Andrew/Linus to hold off on this for now? My preference
Paul Menage wrote:
Hi Balbir,
Andrew included the memrlimit controller in his latest set of patches
to Linus for mainline.
Although the memrlimit controller basically works as intended, my
impression from the mini-summit on Tuesday is that our consensus is
that this still doesn't have
Andrew Morton wrote:
On Fri, 25 Jul 2008 04:14:55 -0400 Paul Menage [EMAIL PROTECTED] wrote:
Hi Balbir,
Andrew included the memrlimit controller in his latest set of patches
to Linus for mainline.
I've asked Linus to drop all 238 patches. I'll be resending them minus
the offending
Andrew Morton wrote:
On Fri, 25 Jul 2008 04:14:55 -0400 Paul Menage [EMAIL PROTECTED] wrote:
Hi Balbir,
Andrew included the memrlimit controller in his latest set of patches
to Linus for mainline.
I've asked Linus to drop all 238 patches. I'll be resending them minus
the offending
Hugh Dickins wrote:
On Fri, 25 Jul 2008, Paul Menage wrote:
So I think we'd be complicating some of the vm paths in mainline with
a feature that isn't likely to get a lot of real use.
What do you (and others on the containers list) think? Should we ask
Andrew/Linus to hold off on this for
On Fri, Jul 25, 2008 at 5:06 AM, Hugh Dickins [EMAIL PROTECTED] wrote:
(Different topic, but one day I ought to get around to saying again
how absurd I think a swap controller; whereas a mem+swap controller
makes plenty of sense. I think Rik and others said the same.)
Agreed that a swap
On Fri, Jul 25, 2008 at 8:30 AM, Balbir Singh [EMAIL PROTECTED] wrote:
There are applications that can/need to handle overcommit, just that we are
not
aware of them fully. Immediately after our meeting, I was pointed to
Paul Menage wrote:
On Fri, Jul 25, 2008 at 8:30 AM, Balbir Singh [EMAIL PROTECTED] wrote:
There are applications that can/need to handle overcommit, just that we are
not
aware of them fully. Immediately after our meeting, I was pointed to
On Fri, 25 Jul 2008, Paul Menage wrote:
On Fri, Jul 25, 2008 at 5:06 AM, Hugh Dickins [EMAIL PROTECTED] wrote:
(Different topic, but one day I ought to get around to saying again
how absurd I think a swap controller; whereas a mem+swap controller
makes plenty of sense. I think Rik and
On Fri, 25 Jul 2008, Balbir Singh wrote:
I'll try and recreate the problem and fix it. If
memrlimit_cgroup_uncharge_as()
created the problem, it's most likely related to mm-owner not being correct
and
we are dereferencing the wrong memory.
Thanks for the bug report, I'll look further.
Hugh Dickins wrote:
On Fri, 25 Jul 2008, Balbir Singh wrote:
I'll try and recreate the problem and fix it. If
memrlimit_cgroup_uncharge_as()
created the problem, it's most likely related to mm-owner not being correct
and
we are dereferencing the wrong memory.
Thanks for the bug report,
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Currently we have three possibilities on how to name pid namespaces.
- indirect via processes
- pids
- names in the filesystem
We discussed this a bit in the hallway track and pids are look like the way
to go. Pavel has a patch in progress
Hugh Dickins wrote:
On Fri, 25 Jul 2008, Paul Menage wrote:
On Fri, Jul 25, 2008 at 5:06 AM, Hugh Dickins [EMAIL PROTECTED] wrote:
(Different topic, but one day I ought to get around to saying again
how absurd I think a swap controller; whereas a mem+swap controller
makes plenty of sense. I
Serge E. Hallyn wrote:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Currently we have three possibilities on how to name pid namespaces.
- indirect via processes
- pids
- names in the filesystem
We discussed this a bit in the hallway track and pids are look like the way
to go. Pavel has
Quoting Daniel Lezcano ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Currently we have three possibilities on how to name pid namespaces.
- indirect via processes
- pids
- names in the filesystem
We discussed this a bit in the hallway track and
Serge E. Hallyn wrote:
Quoting Daniel Lezcano ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Currently we have three possibilities on how to name pid namespaces.
- indirect via processes
- pids
- names in the filesystem
We discussed this a bit
Serge E. Hallyn wrote:
Quoting Daniel Lezcano ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Currently we have three possibilities on how to name pid namespaces.
- indirect via processes
- pids
- names in the filesystem
We discussed this a bit
Create a useless (?) sys_restore system call. All it does
is read a checkpoint file :) for a pid number and a file
to execute.
Since we don't take things like argv and envp and registers
from the checkpoint file, in order to make this easily
testable, we take those things as arguments.
Set the pid number for a restored task. This is purely a toy, as it
only sets the pidnr in the lowest level pid namespace.
Signed-off-by: Serge Hallyn [EMAIL PROTECTED]
---
kernel/fork.c |5 +
kernel/pid.c | 19 +++
2 files changed, 24 insertions(+), 0 deletions(-)
Following is a set of user namespace patches I've been playing with
this week.
The first two patches are I believe fixes which should go in regardless
of which direction user namespaces take.
The rest of the patches are one approach to providing default cross-userns
isolation for files. Any
From ec5f54faf5afd16cb6cef40ebaaf3da25989d185 Mon Sep 17 00:00:00 2001
From: Serge Hallyn [EMAIL PROTECTED]
Date: Thu, 24 Jul 2008 17:52:41 -0500
Subject: [PATCH 2/6] user namespaces: move user_ns from nsproxy into user struct
When we get the sysfs support needed to support fair user scheduling
From 9382f22a6c751e90baa4e7f3ba24c509e50a47a8 Mon Sep 17 00:00:00 2001
From: Serge Hallyn [EMAIL PROTECTED]
Date: Tue, 22 Jul 2008 13:31:37 -0500
Subject: [PATCH 1/6] user namespaces: introduce user_struct-user_namespace
relationship
When a task does clone(CLONE_NEWNS), the task's user is the
From f6d09b06a1106936010bffd420267f5b7ee66238 Mon Sep 17 00:00:00 2001
From: Serge Hallyn [EMAIL PROTECTED]
Date: Wed, 23 Jul 2008 17:01:09 -0500
Subject: [PATCH 3/6] user namespaces: rig generic_permission for simple userns
check
Filesystems can provide their own permission() functions to do
From 4d2c23452a67e25856893ab16fefd0f6e5aa58df Mon Sep 17 00:00:00 2001
From: Serge Hallyn [EMAIL PROTECTED]
Date: Thu, 24 Jul 2008 06:37:43 -0500
Subject: [PATCH 5/6] user namespaces: refuse create in other user_ns
Refuse writing to a directory in another user_ns. We can't
support file creation
Oops, this one was supposed to get folded into the first patch,
obviously. Sorry.
-serge
From daa76939c72adf146ded8a39e0211886e2bc943a Mon Sep 17 00:00:00 2001
From: Serge Hallyn [EMAIL PROTECTED]
Date: Fri, 25 Jul 2008 14:24:32 -0500
Subject: [PATCH 6/6] user_namespace: move put_user_ns
We were talking this morning about what trivial patchset to begin
with to get a start on checkpoint and restart. We thought that
rather than start with checkpoint, maybe we should start with
something that reads a checkpoint file and restarts a single
task. In this case, restart means it sets
On Fri, Jul 25, 2008 at 07:27:25PM -0500, Serge E. Hallyn wrote:
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -600,6 +600,7 @@ struct user_struct {
/* Hash table maintenance information */
struct hlist_node uidhash_node;
uid_t uid;
+ struct user_namespace
Quoting Alexey Dobriyan ([EMAIL PROTECTED]):
On Fri, Jul 25, 2008 at 07:27:25PM -0500, Serge E. Hallyn wrote:
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -600,6 +600,7 @@ struct user_struct {
/* Hash table maintenance information */
struct hlist_node uidhash_node;
29 matches
Mail list logo
