An alternative: the task that created the container namely, is the parent
(outside the container) of the container init(1). In turn, init(1) creates
a special 'monitor' thread that monitors the restart, and the outside task
reaps the exit status of that thread (and only that thread).
[Hmmm...
Again, how would 'cr' obtain exit status for these tasks, and how would
it distinguish failure from normal operation?
Here's our solution to this issue.
mcr maintains in its kernel container object an exitcode attribute for
the mcr-restart process. This process is detached from the fork tree
Oren Laadan or...@cs.columbia.edu wrote:
Nathan Lynch wrote:
Nathan Lynch n...@pobox.com wrote:
Oren Laadan wrote:
Nathan Lynch wrote:
What doesn't work:
* restarting a 32-bit task from a 64-bit task and vice versa
Is there a test to bail if we attempt to checkpoint such tasks ?
More specifically, I envision restart to work like this:
1) user invokes user-land utility (e.g. cr --restart ...
2) 'cr' will create a new container
3) 'cr' will start a child in that container
process 1 in its private namespaces.
4) child will create rest of tree (in kernel or in user
Nathan Lynch wrote:
On Tue, 24 Feb 2009 13:58:26 -0600
Serge E. Hallyn se...@us.ibm.com wrote:
Quoting Nathan Lynch (n...@pobox.com):
Nathan Lynch n...@pobox.com wrote:
Oren Laadan wrote:
Nathan Lynch wrote:
What doesn't work:
* restarting a 32-bit task from a 64-bit task and vice
Nathan Lynch wrote:
Nathan Lynch n...@pobox.com wrote:
Oren Laadan wrote:
Nathan Lynch wrote:
What doesn't work:
* restarting a 32-bit task from a 64-bit task and vice versa
Is there a test to bail if we attempt to checkpoint such tasks ?
No, but I'll add one if it looks too hard to fix
Quoting Nathan Lynch (n...@pobox.com):
Nathan Lynch n...@pobox.com wrote:
Oren Laadan wrote:
Nathan Lynch wrote:
What doesn't work:
* restarting a 32-bit task from a 64-bit task and vice versa
Is there a test to bail if we attempt to checkpoint such tasks ?
No,
On Tue, 24 Feb 2009 13:58:26 -0600
Serge E. Hallyn se...@us.ibm.com wrote:
Quoting Nathan Lynch (n...@pobox.com):
Nathan Lynch n...@pobox.com wrote:
Oren Laadan wrote:
Nathan Lynch wrote:
What doesn't work:
* restarting a 32-bit task from a 64-bit task and vice
Nathan Lynch n...@pobox.com wrote:
Oren Laadan wrote:
Nathan Lynch wrote:
What doesn't work:
* restarting a 32-bit task from a 64-bit task and vice versa
Is there a test to bail if we attempt to checkpoint such tasks ?
No, but I'll add one if it looks too hard to fix for
Quoting Benjamin Herrenschmidt (b...@kernel.crashing.org):
On Wed, 2009-02-04 at 18:44 -0500, Oren Laadan wrote:
* Anything that is decided at compiled time should probably go to the arch-
dependent header.
* Anything that can change at boot time (e.g., for x86 that would include
the
Absolutely, but the accepted way to handle that so far is that if
you want to run an incompatible checkpoint image on a new cpu,
a userspace program will rewrite the image to be correct for the target
cpu.
That doesn't sound nice and definitely not something we want to do on
PowerPC. There
Quoting Benjamin Herrenschmidt (b...@kernel.crashing.org):
+struct cr_hdr_cpu {
+ struct pt_regs pt_regs;
+ /* relevant fields from thread_struct */
+ double fpr[32][TS_FPRWIDTH];
+ unsigned int fpscr;
+ int fpexc_mode;
+ /* unsigned int align_ctl; this is never
On Wed, 2009-02-04 at 09:54 -0600, Serge E. Hallyn wrote:
Quoting Benjamin Herrenschmidt (b...@kernel.crashing.org):
+struct cr_hdr_cpu {
+ struct pt_regs pt_regs;
+ /* relevant fields from thread_struct */
+ double fpr[32][TS_FPRWIDTH];
+ unsigned int fpscr;
+ int
Benjamin Herrenschmidt wrote:
On Wed, 2009-02-04 at 09:54 -0600, Serge E. Hallyn wrote:
Quoting Benjamin Herrenschmidt (b...@kernel.crashing.org):
+struct cr_hdr_cpu {
+ struct pt_regs pt_regs;
+ /* relevant fields from thread_struct */
+ double fpr[32][TS_FPRWIDTH];
+ unsigned int
On Wed, 2009-02-04 at 18:44 -0500, Oren Laadan wrote:
* Anything that is decided at compiled time should probably go to the arch-
dependent header.
* Anything that can change at boot time (e.g., for x86 that would include
the capabilities of the FPU), or even run time (is there any ?) should
+struct cr_hdr_cpu {
+ struct pt_regs pt_regs;
+ /* relevant fields from thread_struct */
+ double fpr[32][TS_FPRWIDTH];
+ unsigned int fpscr;
+ int fpexc_mode;
+ /* unsigned int align_ctl; this is never updated? */
+ unsigned long dabr;
+};
Is there some
Oren Laadan wrote:
Nathan Lynch wrote:
Oren Laadan wrote:
Nathan Lynch wrote:
+ pr_debug(%s: unexpected thread_hdr contents: 0x%lx\n,
+ __func__, (unsigned long)thread_hdr-unimplemented);
Given the macro for 'pr_fmt' in include/linux/checkpoint.h, the use
Nathan,
Thanks for the patch. Looks good, see some comments below.
(disclaimer: I'm not very familiar with ppc architecture)
Nathan Lynch wrote:
The only thing of significance here is that the checkpointed task's
pt_regs and fp state are saved and restored (see cr_write_cpu and
cr_read_cpu);
Hey Oren, thanks for taking a look.
Oren Laadan wrote:
Nathan Lynch wrote:
What doesn't work:
* restarting a 32-bit task from a 64-bit task and vice versa
Is there a test to bail if we attempt to checkpoint such tasks ?
No, but I'll add one if it looks too hard to fix for the next
Nathan Lynch wrote:
Hey Oren, thanks for taking a look.
Oren Laadan wrote:
Nathan Lynch wrote:
What doesn't work:
* restarting a 32-bit task from a 64-bit task and vice versa
Is there a test to bail if we attempt to checkpoint such tasks ?
No, but I'll add one if it looks too hard to
Quoting Oren Laadan (or...@cs.columbia.edu):
+static void cr_hdr_init(struct cr_hdr *hdr, __s16 type, __s16 len, __u32
parent)
+{
+ hdr-type = type;
+ hdr-len = len;
+ hdr-parent = parent;
+}
+
This function is rather generic and useful to non-arch-dependent and other
The only thing of significance here is that the checkpointed task's
pt_regs and fp state are saved and restored (see cr_write_cpu and
cr_read_cpu); the rest of the code consists of dummy implementations
of the APIs the arch needs to provide to the checkpoint/restart core.
What works:
* self and
22 matches
Mail list logo
