Quoting Nathan Lynch (n...@pobox.com):
> > +#if 0
> > + /* Oren's v13 is on an older kernel which has no vdso_base
> > +* on newer kernel, we'll have to enable this
> > +*/
> > + CR_COPY(op, hh->vdso_base, mm->context.vdso_base);
> > +#endif
>
> During restart, does this replace the cu
Quoting David Howells (dhowe...@redhat.com):
> Serge E. Hallyn wrote:
>
> > So you want users to be able to mmap the file and lseek to a particular
> > spot?
>
> mmap? *blink*
/me pretends he didn't say that
> > Meanwhile, do you have any objections to t
Quoting David Howells (dhowe...@redhat.com):
> Serge E. Hallyn wrote:
>
> > Restrict the /proc/keys and /proc/key-users output to keys
> > belonging to the same user namespace as the reading task.
> >
> > We may want to make this more complicated - so that any
>
Quoting Dave Hansen (d...@linux.vnet.ibm.com):
> > Also the double-use of the op seem not very nice to me. Is there any
> > real life use case were you would have the operation on a file but
> > sometimes not allow checkpoiting?
>
> No, I don't have any good concrete ones. The first thing that c
Quoting Sukadev Bhattiprolu (suka...@linux.vnet.ibm.com):
> Dave Hansen [d...@linux.vnet.ibm.com] wrote:
> |
> | 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 s
Quoting Dave Hansen (d...@linux.vnet.ibm.com):
>
> 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
Quoting Alexey Dobriyan (adobri...@gmail.com):
> On Fri, Feb 27, 2009 at 01:31:12AM +0300, Alexey Dobriyan wrote:
> > This is collecting and start of dumping part of cleaned up OpenVZ C/R
> > implementation, FYI.
>
> OK, here is second version which shows what to do with shared objects
> (cr_dump_
Quoting Alexey Dobriyan (adobri...@gmail.com):
> On Sun, Mar 01, 2009 at 02:02:31PM -0600, Serge E. Hallyn wrote:
> > Quoting Alexey Dobriyan (adobri...@gmail.com):
> > > On Fri, Feb 27, 2009 at 01:31:12AM +0300, Alexey Dobriyan wrote:
> > > > This is collectin
Quoting Li Zefan (l...@cn.fujitsu.com):
> devices.allow and devices.deny are write-only, and devices.list is read-only.
>
> Signed-off-by: Li Zefan
Yup that should be intuitive for people.
Acked-by: Serge Hallyn
thanks,
-serge
> ---
> security/device_cgroup.c |3 +++
> 1 files changed,
Quoting Dave Hansen (d...@linux.vnet.ibm.com):
>
> 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
Just sending this out for a sanity check. This is on top of dave's
files_struct may_checkpoint patchset.
>From b696c872296616a03cd7f9791664259c0461bd24 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn
Date: Mon, 2 Mar 2009 10:11:05 -0500
Subject: [PATCH 1/1] checkpoint: Note checkpointab
Quoting Nathan Lynch (n...@pobox.com):
> On Mon, 2 Mar 2009 07:37:54 -0600
> "Serge E. Hallyn" wrote:
>
> > Quoting Dave Hansen (d...@linux.vnet.ibm.com):
> > >
> > > Introduce a files_struct counter to indicate whether a particular
> > > fi
Quoting Dave Hansen (d...@linux.vnet.ibm.com):
> On Mon, 2009-03-02 at 11:22 -0600, Nathan Lynch wrote:
> > No.. I mean what if a process 1234 does
> >
> > f = fopen("/proc/1234/stat", "r");
> >
> > and is then checkpointed. Can that path be resolved during restart,
> > before pid 1234 is alive?
Quoting Dave Hansen (d...@linux.vnet.ibm.com):
> On Mon, 2009-03-02 at 11:44 -0600, Serge E. Hallyn wrote:
> > Quoting Dave Hansen (d...@linux.vnet.ibm.com):
> > > On Mon, 2009-03-02 at 11:22 -0600, Nathan Lynch wrote:
> > > > No.. I mean what if a process 1234 d
Quoting Dave Hansen (d...@linux.vnet.ibm.com):
> Christoph's suggestion that we go add f_ops individually is a really
> good way to get people thinking about individual cases that we have to
> deal with.
>
> Can we checkpoint an *open* /proc/mounts? I don't think we want to. It
> could get reall
Any objections to this patch?
>From cfecafff4d4b1bb0f8fd49eb8e19384b34a7dc22 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn
Date: Mon, 2 Mar 2009 16:40:18 -0800
Subject: [PATCH 1/1] ipc namespace: initialize init_ipc_ns.count to 1
That's one count for the init task. Nothing else pins a
Quoting Cedric Le Goater (legoa...@free.fr):
>
> >> 1. cap_sys_admin check is unfortunate. In discussions about Oren's
> >> patchset we've agreed that not having that check from the outset forces
> >> us to consider security with each new patch and feature, which is a good
> >> thing.
> >
> > Re
Quoting Dan Smith (da...@us.ibm.com):
> Implement the s390 arch-specific checkpoint/restart helpers. This
> is on top of Oren Laadan's c/r code.
Working nicely for me, thanks.
-serge
___
Containers mailing list
contain...@lists.linux-foundation.org
htt
Quoting Dave Hansen (d...@linux.vnet.ibm.com):
> On Tue, 2009-03-03 at 16:57 -0800, Dan Smith wrote:
> > DH> Did you convince Nathan that this ends up being a good idea?
> >
> > Technically he hasn't seen this version, but my hopes are not high
> > that he will change his mind. If the feedback is
drops the count to 1. No pre-init resources other than tasks pin (and
therefore can decrease the refcount on) an ipc_ns.
Signed-off-by: Serge E. Hallyn
---
ipc/msgutil.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/ipc/msgutil.c b/ipc/msgutil.c
index e5d6da1
Quoting Dan Smith (da...@us.ibm.com):
> SH> +static inline void task_show_checkpointable(struct seq_file *m,
> SH> + struct task_struct *p)
> SH> +{
> SH> + if (test_bit(0, &p->mm->may_checkpoint))
> SH> + seq_printf(m, "mm is checkpointable\n");
>
[ this is on top of Dave's version of Oren's patchset, i.e.
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/daveh/linux-2.6-cr.git;a=shortlog;h=dave-v13.4
]
Define pid=0 when calling sys_checkpoint as asking for
a self-checkpoint.
Signed-off-by: Serge E. Hallyn
---
checkpoint/sy
I need the following to get fdinfo checkpointability output:
>From 4002821bf068c122867c3b1819817f0b1fdfc250 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn
Date: Thu, 5 Mar 2009 10:12:30 -0800
Subject: [PATCH 1/1] checkpointable: add missing trailing \n for fdinfo output
Signed-off-by: Serg
Quoting Dave Hansen (d...@linux.vnet.ibm.com):
> On Fri, 2009-03-06 at 01:00 +0300, Alexey Dobriyan wrote:
> > On Thu, Mar 05, 2009 at 01:27:07PM -0800, Dave Hansen wrote:
> > > > Imagine, unsupported file is opened between userspace checks
> > > > for /proc/*/checkpointable and /proc/*/fdinfo/*/ch
Quoting Greg Kurz (gk...@fr.ibm.com):
> On Fri, 2009-03-06 at 01:00 +0300, Alexey Dobriyan wrote:
> > On Thu, Mar 05, 2009 at 01:27:07PM -0800, Dave Hansen wrote:
> > > > Imagine, unsupported file is opened between userspace checks
> > > > for /proc/*/checkpointable and /proc/*/fdinfo/*/checkpointa
Quoting Dave Hansen (d...@linux.vnet.ibm.com):
> On Fri, 2009-03-06 at 08:34 -0600, Serge E. Hallyn wrote:
> > > > With time the amount of stuff C/R won't support will approach zero,
> > > > but the infrastructure for "checkpointable" will stay constant.
&
Quoting Dave Hansen (d...@linux.vnet.ibm.com):
> On Fri, 2009-03-06 at 10:23 -0600, Serge E. Hallyn wrote:
> > Which imo is fine, but my question is whether that leaves any actual
> > value in the persistent per-resource uncheckpointable flag.
>
> OK, let's take a look
Quoting Cedric Le Goater (legoa...@free.fr):
> Serge E. Hallyn wrote:
> > Quoting Greg Kurz (gk...@fr.ibm.com):
> >> On Fri, 2009-03-06 at 01:00 +0300, Alexey Dobriyan wrote:
> >>> On Thu, Mar 05, 2009 at 01:27:07PM -0800, Dave Hansen wrote:
> >>>>
[ this set is on top of Dave's c/r tree ]
We'll be using it from files other than ckpt_mem.c soon.
Signed-off-by: Serge E. Hallyn
---
checkpoint/ckpt_mem.c |3 ---
include/linux/checkpoint.h |3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/
Add file checkpointability info at the end of /proc/pid/status
output. This will next be augmented by vm checkpointability
info.
Signed-off-by: Serge E. Hallyn
---
checkpoint/checkpoint.c| 14 ++
fs/proc/array.c|2 ++
include/linux/checkpoint.h |4
3
uncheckpointable.
I realize vm_stat_account() may seem like an odd choice, but it
really seems like the best fit...
Signed-off-by: Serge E. Hallyn
---
checkpoint/checkpoint.c| 24
include/linux/checkpoint.h | 32
include/linux
define s390x signalfd for systems with headers which are too
old.
Signed-off-by: Serge Hallyn
---
src/lxc/start.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/lxc/start.c b/src/lxc/start.c
index 410235c..476d695 100644
--- a/src/lxc/start.c
+++ b/src/lxc/start.
Switch the flags and sp for sys_clone for s390.
Without this, lxc-execute gets a segfault on clone (of course).
With this, it succeeds.
Signed-off-by: Serge Hallyn
---
src/lxc/lxc_namespace.h |4 +++-
src/lxc/namespace.h |4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
di
Quoting Nathan Lynch (n...@pobox.com):
> Please consider this and a following patch.
>
> >From a0fb96aa41c4d360559013cfd7f32f07f449c1c4 Mon Sep 17 00:00:00 2001
> From: Nathan Lynch
> Date: Mon, 9 Mar 2009 22:23:02 -0500
> Subject: [PATCH] checkpoint: make files_deny_checkpointing print task name
Quoting Nathan Lynch (n...@pobox.com):
> >From 3695fbda6225d2436e4af67a4bce6984df0891be Mon Sep 17 00:00:00 2001
> From: Nathan Lynch
> Date: Mon, 9 Mar 2009 22:36:40 -0500
> Subject: [PATCH] ratelimit files_deny_checkpointing output
>
> Any common distribution's boot sequence causes thousands of
Quoting Nathan Lynch (n...@pobox.com):
> "Serge E. Hallyn" wrote:
> > Quoting Nathan Lynch (n...@pobox.com):
> > > Please consider this and a following patch.
> > >
> > > >From a0fb96aa41c4d360559013cfd7f32f07f449c1c4 Mon Sep 17 00:00:00 2001
>
Quoting Alexey Dobriyan (adobri...@gmail.com):
> On Thu, Feb 26, 2009 at 06:57:55PM +0300, Alexey Dobriyan wrote:
> > On Thu, Feb 12, 2009 at 03:04:05PM -0800, Dave Hansen wrote:
> > > d...@nimitz:~/kernels/linux-2.6-openvz$ git diff v2.6.27.10...
> > > kernel/cpt/ | diffstat
>
> > > 47 files c
Quoting Cedric Le Goater (legoa...@free.fr):
> Alexey Dobriyan wrote:
> > On Thu, Feb 26, 2009 at 06:57:55PM +0300, Alexey Dobriyan wrote:
> >> On Thu, Feb 12, 2009 at 03:04:05PM -0800, Dave Hansen wrote:
> >>> d...@nimitz:~/kernels/linux-2.6-openvz$ git diff v2.6.27.10...
> >>> kernel/cpt/ | diff
Quoting Cedric Le Goater (legoa...@free.fr):
> >> And if Ingo's requirement is fulfilled, would any C/R patchset be
> >> acceptable ?
> >
> > Yup, no matter how hideous :) Ok not really.
> >
> > But the point was that it wasn't Dave not understanding Alexey's
> > suggestion, but Greg not under
Quoting Sukadev Bhattiprolu (suka...@linux.vnet.ibm.com):
Hi Suka,
the reason this patch was dropped is that we've moved from
task to slightly more per-resource checkpointability tracking.
So right now there is no t->may_checkpoint, but there is
t->files->may_checkpoint and t->mm->may_checkpoint
Quoting Sukadev Bhattiprolu (suka...@linux.vnet.ibm.com):
>
> From: Sukadev Bhattiprolu
> Subject: [PATCH 4/5] Check 'may_checkpoint()' early
>
> We currently check if a task is checkpointable when writing the task
> information to checkpoint file. The small downside of doing this check
> late i
Quoting Sukadev Bhattiprolu (suka...@linux.vnet.ibm.com):
>
> From: Sukadev Bhattiprolu
> Subject: [PATCH 5/5] Deny external checkpoint unless task is frozen
>
> Remove a 'FIXME' and ensure that the tasks we are checkpointing are
> frozen unless its a self-checkpoint.
>
> Signed-off-by: Sukadev
Quoting Li Zefan (l...@cn.fujitsu.com):
> There is nothing special that has to be protected by cgroup_lock,
> so introduce devcgroup_mtuex for it's own use.
>
> Signed-off-by: Li Zefan
> ---
> security/device_cgroup.c | 21 +
> 1 files changed, 13 insertions(+), 8 deletions
Quoting Greg Kurz (gk...@fr.ibm.com):
> On Thu, 2009-03-12 at 09:53 -0500, Serge E. Hallyn wrote:
> > Or are you suggesting that you'll do a dummy clone of (5594,2) so that
> > the next clone(CLONE_NEWPID) will be expected to be (5594,3,1)?
> >
>
> Of course not
Quoting Dan Smith (da...@us.ibm.com):
> NL> I'd like there to be some discussion about this, because namespace
> NL> creation seems like a significant addition to the semantics of
> NL> restart as I understand it.
>
> Indeed.
>
> NL> Is namespace creation during restart unavoidable, or merely
> N
Quoting Dan Smith (da...@us.ibm.com):
> SH> Well it forces restart to go through the established userspace
> SH> API's when creating resources (in this case, tasks and namespaces)
> SH> which means any existing security guarantees are leveraged.
>
> That's a very valid point. However, it still se
Quoting Li Zefan (l...@cn.fujitsu.com):
> >> @@ -426,11 +431,11 @@ static int devcgroup_access_write(struct cgroup
> >> *cgrp, struct cftype *cft,
> >> const char *buffer)
> >> {
> >>int retval;
> >> - if (!cgroup_lock_live_group(cgrp))
> >
> > Does it matter th
Quoting Oren Laadan (or...@cs.columbia.edu):
>
>
> Serge E. Hallyn wrote:
> > Quoting Sukadev Bhattiprolu (suka...@linux.vnet.ibm.com):
> >> From: Sukadev Bhattiprolu
> >> Subject: [PATCH 5/5] Deny external checkpoint unless task is frozen
> >>
> >
Quoting Daniel Lezcano (daniel.lezc...@free.fr):
> Dan Smith wrote:
> > DL> I guess it will be esay to implement with a nsproxy level counter.
> > DL> Each time you unshare, the new nsproxy count is incremented.
> > DL> Assuming the init_nsproxy is level 0, when the nsproxy counter is
> > DL> > 1,
Quoting Cedric Le Goater (legoa...@free.fr):
>
> > No, what you're suggesting does not suffice.
>
> probably. I'm still trying to understand what you mean below :)
>
> Man, I hate these hierarchicals pid_ns. one level would have been enough,
> just one vpid attribute in 'struct pid*'
Well I do
Quoting Daniel Lezcano (daniel.lezc...@free.fr):
> Serge E. Hallyn wrote:
>> Quoting Daniel Lezcano (daniel.lezc...@free.fr):
>>
>>> Dan Smith wrote:
>>>
>>>> DL> I guess it will be esay to implement with a nsproxy level counter.
>>
Quoting Ying Han (ying...@google.com):
> Hi Serge:
> I made a patch based on Oren's tree recently which implement a new
> syscall clone_with_pid. I tested with checkpoint/restart process tree
> and it works as expected.
> This patch has some hack in it which i made a copy of libc's clone and
> made
Quoting Matt Helsley (matth...@us.ibm.com):
> On Thu, Mar 12, 2009 at 10:30:48AM -0500, Serge E. Hallyn wrote:
> > Quoting Cedric Le Goater (legoa...@free.fr):
> > > >> And if Ingo's requirement is fulfilled, would any C/R patchset be
> > > >> acce
Quoting Linus Torvalds (torva...@linux-foundation.org):
>
>
> On Thu, 12 Mar 2009, Sukadev Bhattiprolu wrote:
>
> > Ying Han [ying...@google.com] wrote:
> > | Hi Serge:
> > | I made a patch based on Oren's tree recently which implement a new
> > | syscall clone_with_pid. I tested with checkpoint
Quoting Serge E. Hallyn (se...@us.ibm.com):
> Quoting Li Zefan (l...@cn.fujitsu.com):
> > >> @@ -426,11 +431,11 @@ static int devcgroup_access_write(struct cgroup
> > >> *cgrp, struct cftype *cft,
> > >>const char *buffe
Quoting Eric W. Biederman (ebied...@xmission.com):
> Alexey Dobriyan writes:
>
> > On Fri, Feb 13, 2009 at 12:45:03PM +0100, Ingo Molnar wrote:
> >>
> >> * Alexey Dobriyan wrote:
> >>
> >> > On Fri, Feb 13, 2009 at 11:27:32AM +0100, Ingo Molnar wrote:
> >> > > Merging checkpoints instead might
Quoting Dan Smith (da...@us.ibm.com):
> Read the namespace records from the restore stream and do the unshare()
> necessary to create a new namespace. For UTS, set hostname and domainname
> to match what was stored in the checkpoint.
>
> Signed-off-by: Dan Smith
> ---
> mktree.c | 66
> +
Quoting Dan Smith (da...@us.ibm.com):
> This patch adds a "phase" of checkpoint that saves out information about any
> namespaces the task(s) may have. Do this by tracking the nsproxy of the
> first task and making sure that the tasks that follow get hooked back to
> share the same one on restart.
Quoting Dan Smith (da...@us.ibm.com):
> SH> Someone might complain about the per-task namespace data not
> SH> showing up in the per-task data, but I think the way you have it
> SH> simplifies things enough to justify it.
>
> Yeah, mktree would get pretty ugly without doing it ahead of time, I
> t
Quoting Sukadev Bhattiprolu (suka...@linux.vnet.ibm.com):
>
> From: Sukadev Bhattiprolu
> Date: Sat, 14 Mar 2009 10:21:07 -0700
> Subject: [PATCH 6/6] Explain reason for task being uncheckpointable
>
> Try to give an useful message on why a task is uncheckpointable.
As I said somewhere else, I
Quoting Alexey Dobriyan (adobri...@gmail.com):
> > +Keeping the restart procedure to operate within the limits of the
> > +caller's credentials means that there various scenarios that cannot
> > +be supported. For instance, a setuid program that opened a protected
> > +log file and then dropped pri
Quoting Oren Laadan (or...@cs.columbia.edu):
>
>
> Serge E. Hallyn wrote:
> > Quoting Dave Hansen (d...@linux.vnet.ibm.com):
> >> On Tue, 2009-03-03 at 16:57 -0800, Dan Smith wrote:
> >>> DH> Did you convince Nathan that this ends up being a good idea?
>
Quoting Oren Laadan (or...@cs.columbia.edu):
>
>
> Dan Smith wrote:
> > SH> Well it forces restart to go through the established userspace
> > SH> API's when creating resources (in this case, tasks and namespaces)
> > SH> which means any existing security guarantees are leveraged.
> >
> > That's
Quoting Oren Laadan (or...@cs.columbia.edu):
>
>
> Sukadev Bhattiprolu wrote:
> > From: Sukadev Bhattiprolu
> > Date: Sat, 14 Mar 2009 10:21:07 -0700
> > Subject: [PATCH 6/6] Explain reason for task being uncheckpointable
> >
> > Try to give an useful message on why a task is uncheckpointable.
Quoting Oren Laadan (or...@cs.columbia.edu):
>
>
> Sukadev Bhattiprolu wrote:
> > From: Sukadev Bhattiprolu
> > Date: Fri, 13 Mar 2009 17:25:42 -0700
> > Subject: [PATCH 5/6] Define and use proc_pid_checkpointable()
> >
> > Create a proc file, /proc/pid/checkpointable, which shows '1' if
> > ta
Quoting Oren Laadan (or...@cs.columbia.edu):
>
>
> Serge E. Hallyn wrote:
> > Quoting Oren Laadan (or...@cs.columbia.edu):
> >>
> >> Sukadev Bhattiprolu wrote:
> >>> From: Sukadev Bhattiprolu
> >>> Date: Fri, 13 Mar 2009
PATCHED
User 1: user root inside userns created by userid serge
User 2: hallyn
==
User 1 User 2
run 1: 3m9.876s2m8.428s
run 2: 3m8.539s2m6.356s
Signed-off-by: Serge E. Hallyn
Signed-off-by: Dhaval Giani
Quoting Matt Helsley (matth...@us.ibm.com):
> On Thu, Mar 19, 2009 at 04:16:15PM -0500, Serge E. Hallyn wrote:
> > In a kernel compiled with CONFIG_USER_SCHED=y, cpu shares are
> > allocated according to uid. Shares are specifiable under
> > /sys/kernel/uids//
> >
&g
duce any new references to new->user_ns.
>
> Otherwise looks good to me.
Here is the new version. Thanks again.
>From 55c264b27cb1f6f91007ae2aeda2d4f6067bb2eb Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn
Date: Wed, 18 Mar 2009 13:29:32 -0700
Subject: [PATCH] introduce user_ns i
Quoting Eric W. Biederman (ebied...@xmission.com):
> Ok. I see what you are trying to accomplish with this and honestly I
> think it is silly.
>
> We should start the threads we need in the kernel, and if we need to
> run clone_pid fine. I am not comfortable exporting clone_with_pid to
> user sp
Quoting Oren Laadan (or...@cs.columbia.edu):
>
>
> Dan Smith wrote:
> > OL> So what happens in the following scenario:
> >
> > OL> * task A is the container init(1)
> > OL> * A calls fork() to create task B
> > OL> * B calls unshare(CLONE_NEWUTS)
> > OL> * B calls clone(CLONE_PARENT) to create t
Quoting Oren Laadan (or...@cs.columbia.edu):
> What got me confused was that you loop over all tasks, which is not
> needed because was assume they all share the name nsproxy; And in
> restart, you unshare() many times by the same task, so all but the
> last unshare() are useless. In other words,
Quoting Mike Waychison (mi...@google.com):
> Serge E. Hallyn wrote:
>> Quoting Eric W. Biederman (ebied...@xmission.com):
>>> Ok. I see what you are trying to accomplish with this and honestly I
>>> think it is silly.
>>>
>>> We should start the thr
Quoting Oren Laadan (or...@cs.columbia.edu):
>
>
> Serge E. Hallyn wrote:
> > Quoting Oren Laadan (or...@cs.columbia.edu):
> >>
> >> Dan Smith wrote:
> >>> OL> So what happens in the following scenario:
> >>>
> >>> OL> *
Quoting Oren Laadan (or...@cs.columbia.edu):
> Changelog[v14]:
> - Define sys_checkpoint(0,...) as asking for a self-checkpoint (Serge)
Thanks.
> - Revert use of 'pr_fmt' to avoid tainting whom includes us (Nathan Lynch)
> - Explicitly indicate length of UTS fields in header
> - Discard f
Quoting Oren Laadan (or...@cs.columbia.edu):
>
>
> Serge E. Hallyn wrote:
> > Quoting Oren Laadan (or...@cs.columbia.edu):
> >> Changelog[v14]:
> >> - Define sys_checkpoint(0,...) as asking for a self-checkpoint (Serge)
> >
> > Thanks.
> >
Quoting Oren Laadan (or...@cs.columbia.edu):
> + ret = -EINVAL;
> + if (hh->vdso != (unsigned long) mm->context.vdso)
> + goto out;
We were just talking about vdso+s390 on irc this morning,
wondering about how to handle it...
Looking at arch/x86/vdso/vma.c, this seems like it
Quoting Eric W. Biederman (ebied...@xmission.com):
> > What is wrong with Alexey's patch, which simply passes in the values
> > themselves? Do you have another use in mind for the min/max pid
> > values?
>
> At an implementation level (and I need to look at Alexey's specific patch)
> every patch
Quoting Peter Zijlstra (pet...@infradead.org):
> On Thu, 2009-03-19 at 16:16 -0500, Serge E. Hallyn wrote:
> > In a kernel compiled with CONFIG_USER_SCHED=y, cpu shares are
> > allocated according to uid. Shares are specifiable under
> > /sys/kernel/uids//
> >
&g
Quoting Eric W. Biederman (ebied...@xmission.com):
> "Serge E. Hallyn" writes:
>
> > Quoting Eric W. Biederman (ebied...@xmission.com):
> >> > What is wrong with Alexey's patch, which simply passes in the values
> >> > themselves?
Quoting Oren Laadan (or...@cs.columbia.edu):
>
>
> Serge E. Hallyn wrote:
> > Quoting Oren Laadan (or...@cs.columbia.edu):
> >> + ret = -EINVAL;
> >> + if (hh->vdso != (unsigned long) mm->context.vdso)
> >> + goto out;
> >
> &
Quoting Dan Smith (da...@us.ibm.com):
> DH> for each ns in nsproxy {
> DH> if (ns seen first time) {
> DH> alloc ns_objref
> DH> save state of ns
> DH> } else {
> DH> save existing ns_objref
> DH> }
> DH> }
>
> Isn't this precisely what I have in the latest patch? Since there is
Quoting Oren Laadan (or...@cs.columbia.edu):
> From: Dan Smith
>
> As suggested by Dave[1], this provides us a way to make the copy-in and
> copy-out processes symmetric. CR_COPY_ARRAY() provides us a way to do
> the same thing but for arrays. It's not critical, but it helps us unify
> the chec
Quoting Dave Hansen (d...@linux.vnet.ibm.com):
> On Fri, 2009-03-20 at 16:55 -0400, Oren Laadan wrote:
> > Dave Hansen wrote:
> > > On Fri, 2009-03-20 at 14:47 -0400, Oren Laadan wrote:
> > >> + switch (inode->i_mode & S_IFMT) {
> > >> + case S_IFREG:
> > >> + fd_type = CR
Quoting Oren Laadan (or...@cs.columbia.edu):
>
>
> Serge E. Hallyn wrote:
> > Did this thread die because we expect Dave's fops patch to make
> > this absolete?
>
> and I thought it just ended :)
> (in fact the change is already in the current ckp
Make a few changes to the s390 c/r code to reflect v14 changes.
CONFIG_CHECKPOINT_RESTART is now CONFIG_CHECKPOINT, and 'parent'
is gone.
Signed-off-by: Serge E. Hallyn
---
arch/s390/mm/Makefile |2 +-
arch/s390/mm/checkpoint.c |5 +
2 files changed, 2 insertions(+), 5
Uh, discard the previous version :)
Make a few changes to the s390 c/r code to reflect v14 changes.
CONFIG_CHECKPOINT_RESTART is now CONFIG_CHECKPOINT, and 'parent'
is gone.
Compiler missed another use of parent. This version actually
is tested with a working c/r :)
Signed-off-b
ret can be used undefined at bottom
Signed-off-by: Serge E. Hallyn
---
checkpoint/ckpt_mem.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/checkpoint/ckpt_mem.c b/checkpoint/ckpt_mem.c
index 7cfeac3..b1b50b5 100644
--- a/checkpoint/ckpt_mem.c
+++ b/checkpoint
Trivial fix.
Signed-off-by: Serge E. Hallyn
---
checkpoint/rstr_file.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/checkpoint/rstr_file.c b/checkpoint/rstr_file.c
index de260dc..c9d75e5 100644
--- a/checkpoint/rstr_file.c
+++ b/checkpoint/rstr_file.c
@@ -236,7
10 seconds, and
then restarting it, will end up with bad __vdso_gettimeofday()
results without this patch, and good ones with it.
-serge
>From f79593f4b17bef93b067584c6222fa9e510ab5a7 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn
Date: Tue, 24 Mar 2009 15:07:40 -0400
Subject: [PATCH 1/1]
Quoting anqin (anqin@gmail.com):
> Dear all,
>
> I have met a straight problem in my recent operation.
> Previously, I can do the following operations:
>
> # mount -t cgroup cgroup /mnt/cgrp
> # cd /mnt/cgrp
> # mkdir test
> # echo $$ > test/tasks
> # rm -rf test
I doubt this ever worked -
Quoting Eric W. Biederman (ebied...@xmission.com):
> Dave Hansen writes:
>
> > On Wed, 2009-03-18 at 13:03 -0700, Mike Waychison wrote:
> >> Polluting the dmesg buffer with messages from common failures (consider
> >> a multi-user cluster where checkpoints may or may not succeed) isn't
> >> ver
Quoting Nathan Lynch (n...@pobox.com):
> Only 64-bit kernels are supported.
>
> Signed-off-by: Nathan Lynch
Acked-by: Serge Hallyn
> ---
> arch/s390/Kconfig |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 6b0a353.
Quoting Nathan Lynch (n...@pobox.com):
> For now, supported only for 32-bit kernels.
>
> Signed-off-by: Nathan Lynch
Acked-by: Serge Hallyn
> ---
> arch/x86/Kconfig |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index bc
Quoting Nathan Lynch (n...@pobox.com):
> Instead of trying to maintain a fruit salad of architecture names and
> options in the dependency list, have architectures define
> CHECKPOINT_SUPPORT in their respective Kconfigs when they have
> implemented the arch-specific C/R hooks.
>
> Signed-off-by:
Quoting Li Zefan (l...@cn.fujitsu.com):
> anqin wrote:
> >> Yes you have to initialize some cpuset files first. Otherwise
> >> the tasks have no access to any memory or cpus.
> >>
> >
> > Oh... thank you for reminding. Previously, I run my tests in
> > a experimental kernel, it seems someone has
Quoting Sukadev Bhattiprolu (suka...@linux.vnet.ibm.com):
>
> Oren,
>
> I see that patch 3/6 (deny external checkpoint unless frozen) in this
> set was merged in v14, but do you have any plans/objections to merging
> this optimization patch ? Serge had acked an earlier version of this
> patch.
>
Quoting Cedric Le Goater (legoa...@free.fr):
> Serge E. Hallyn wrote:
> > Quoting Eric W. Biederman (ebied...@xmission.com):
> >> Dave Hansen writes:
> >>
> >>> On Wed, 2009-03-18 at 13:03 -0700, Mike Waychison wrote:
> >>>> Polluting the dme
Quoting Daniel Lezcano (daniel.lezc...@free.fr):
> Chris R. Jones wrote:
> > I have a couple of basic configuration questions on linux containers. I'm
> > using lxc-0.6.1.
> >
> > I'm trying to configure a setup where I have two containers, where the only
> > virtualized/isolated resources are n
Quoting Oren Laadan (or...@cs.columbia.edu):
>
>
> Serge E. Hallyn wrote:
> > Well, here is my current attempt at properly handling vdso for
> > the x86 and s390 c/r code. I was going to test with gettimeofday,
> > but x86 doesn't use vdso for that, and I'
201 - 300 of 2246 matches
Mail list logo
