From: Louis Rilling <Louis.Rilling@kerlabs.com>
To: Oren Laadan <orenl@cs.columbia.edu>
Cc: dave@linux.vnet.ibm.com, arnd@arndb.de, jeremy@goop.org,
linux-kernel@vger.kernel.org,
containers@lists.linux-foundation.org
Subject: Re: [RFC v2][PATCH 2/9] General infrastructure for checkpoint restart
Date: Thu, 21 Aug 2008 11:35:29 +0200 [thread overview]
Message-ID: <20080821093529.GG581@hawkmoon.kerlabs.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0808202303460.17436@takamine.ncl.cs.columbia.edu>
[-- Attachment #1: Type: text/plain, Size: 4410 bytes --]
On Wed, Aug 20, 2008 at 11:04:13PM -0400, Oren Laadan wrote:
>
> Add those interfaces, as well as helpers needed to easily manage the
> file format. The code is roughly broken out as follows:
>
> ckpt/sys.c - user/kernel data transfer, as well as setup of the
> checkpoint/restart context (a per-checkpoint data structure for
> housekeeping)
>
> ckpt/checkpoint.c - output wrappers and basic checkpoint handling
>
> ckpt/restart.c - input wrappers and basic restart handling
>
> Patches to add the per-architecture support as well as the actual
> work to do the memory checkpoint follow in subsequent patches.
>
[...]
> diff --git a/checkpoint/sys.c b/checkpoint/sys.c
> new file mode 100644
> index 0000000..2891c48
> --- /dev/null
> +++ b/checkpoint/sys.c
[...]
> +/*
> + * helpers to manage CR contexts: allocated for each checkpoint and/or
> + * restart operation, and persists until the operation is completed.
> + */
> +
> +static atomic_t cr_ctx_count; /* unique checkpoint identifier */
I thought we agreed that this counter should be per-container. Perhaps add a
TODO here?
> +
> +void cr_ctx_free(struct cr_ctx *ctx)
> +{
> +
> + if (ctx->file)
> + fput(ctx->file);
> + if (ctx->vfsroot)
> + path_put(ctx->vfsroot);
> +
> + free_pages((unsigned long) ctx->tbuf, CR_TBUF_ORDER);
> + free_pages((unsigned long) ctx->hbuf, CR_HBUF_ORDER);
> +
> + kfree(ctx);
> +}
> +
> +struct cr_ctx *cr_ctx_alloc(pid_t pid, struct file *file, unsigned long flags)
> +{
> + struct cr_ctx *ctx;
> +
> + ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> + if (!ctx)
> + return NULL;
> +
> + ctx->tbuf = (void *) __get_free_pages(GFP_KERNEL, CR_TBUF_ORDER);
> + ctx->hbuf = (void *) __get_free_pages(GFP_KERNEL, CR_HBUF_ORDER);
> + if (!ctx->tbuf || !ctx->hbuf)
> + goto nomem;
> +
> + ctx->pid = pid;
> + ctx->flags = flags;
> +
> + ctx->file = file;
> + get_file(file);
> +
> + /* assume checkpointer is in container's root vfs */
I'm a bit puzzled by this assumption. I would say: either this is a
self-checkpoint (only current process), or this is a container checkpoint. In
the latter case, I expect that in the general case the checkpointer lives
outside the container (and the interface of sys_checkpoint() below confirms
this), so it's root fs is probably not the container's one.
Does it differ from what you're planning?
Thanks,
Louis
> + ctx->vfsroot = ¤t->fs->root;
> + path_get(ctx->vfsroot);
> +
> + ctx->crid = atomic_inc_return(&cr_ctx_count);
> +
> + return ctx;
> +
> + nomem:
> + cr_ctx_free(ctx);
> + return NULL;
> +}
> +
> +/**
> + * sys_checkpoint - checkpoint a container
> + * @pid: pid of the container init(1) process
> + * @fd: file to which dump the checkpoint image
> + * @flags: checkpoint operation flags
> + */
> +asmlinkage long sys_checkpoint(pid_t pid, int fd, unsigned long flags)
> +{
> + struct cr_ctx *ctx;
> + struct file *file;
> + int fput_needed;
> + int ret;
> +
> + file = fget_light(fd, &fput_needed);
> + if (!file)
> + return -EBADF;
> +
> + /* no flags for now */
> + if (flags)
> + return -EINVAL;
> +
> + ctx = cr_ctx_alloc(pid, file, flags | CR_CTX_CKPT);
> + if (!ctx) {
> + fput_light(file, fput_needed);
> + return -ENOMEM;
> + }
> +
> + ret = do_checkpoint(ctx);
> +
> + cr_ctx_free(ctx);
> + fput_light(file, fput_needed);
> +
> + return ret;
> +}
> +
> +/**
> + * sys_restart - restart a container
> + * @crid: checkpoint image identifier
> + * @fd: file from which read the checkpoint image
> + * @flags: restart operation flags
> + */
> +asmlinkage long sys_restart(int crid, int fd, unsigned long flags)
> +{
> + struct cr_ctx *ctx;
> + struct file *file;
> + int fput_needed;
> + int ret;
> +
> + file = fget_light(fd, &fput_needed);
> + if (!file)
> + return -EBADF;
> +
> + /* no flags for now */
> + if (flags)
> + return -EINVAL;
> +
> + ctx = cr_ctx_alloc(crid, file, flags | CR_CTX_RSTR);
> + if (!ctx) {
> + fput_light(file, fput_needed);
> + return -ENOMEM;
> + }
> +
> + ret = do_restart(ctx);
> +
> + cr_ctx_free(ctx);
> + fput_light(file, fput_needed);
> +
> + return ret;
> +}
--
Dr Louis Rilling Kerlabs
Skype: louis.rilling Batiment Germanium
Phone: (+33|0) 6 80 89 08 23 80 avenue des Buttes de Coesmes
http://www.kerlabs.com/ 35700 Rennes
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2008-08-21 9:35 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-21 2:58 [RFC v2][PATCH 1/9] kernel based checkpoint-restart Oren Laadan
2008-08-21 3:03 ` [RFC v2][PATCH 1/9] Create trivial sys_checkpoint/sys_restart syscalls Oren Laadan
2008-08-21 5:17 ` Oren Laadan
2008-08-22 19:32 ` Dave Hansen
2008-08-22 20:11 ` Dave Hansen
2008-08-22 21:20 ` Oren Laadan
2008-08-21 3:04 ` [RFC v2][PATCH 2/9] General infrastructure for checkpoint restart Oren Laadan
2008-08-21 9:35 ` Louis Rilling [this message]
2008-08-24 5:58 ` Oren Laadan
2008-08-22 20:01 ` Dave Hansen
2008-08-25 2:47 ` Oren Laadan
2008-08-26 16:42 ` Dave Hansen
2008-08-27 0:38 ` Oren Laadan
2008-08-21 3:04 ` [RFC v2][PATCH 3/9] x86 support for checkpoint/restart Oren Laadan
2008-08-22 20:17 ` Dave Hansen
2008-08-21 3:05 ` [RFC v2][PATCH 4/9] Memory management - dump state Oren Laadan
2008-08-21 7:30 ` Ingo Molnar
2008-08-21 8:01 ` Justin P. Mattock
2008-08-21 10:28 ` Balbir Singh
2008-08-21 11:59 ` Ingo Molnar
2008-08-21 9:53 ` Louis Rilling
2008-08-22 21:21 ` Oren Laadan
2008-08-22 20:37 ` Dave Hansen
2008-08-24 5:40 ` Oren Laadan
2008-08-26 16:33 ` Dave Hansen
2008-08-27 0:14 ` Oren Laadan
2008-08-27 15:41 ` Dave Hansen
2008-08-27 15:57 ` Louis Rilling
2008-08-27 16:12 ` Dave Hansen
2008-08-27 16:19 ` Jeremy Fitzhardinge
2008-08-27 20:34 ` Serge E. Hallyn
2008-08-27 20:38 ` Dave Hansen
2008-08-27 20:48 ` Serge E. Hallyn
2008-08-27 20:56 ` Dave Hansen
2008-08-31 7:16 ` Oren Laadan
2008-08-31 17:34 ` Cedric Le Goater
2008-09-03 11:43 ` [Devel] " Andrey Mirkin
2008-09-03 12:15 ` Cedric Le Goater
2008-09-03 13:29 ` Andrey Mirkin
2008-09-02 15:32 ` Serge E. Hallyn
2008-08-21 3:05 ` [RFC v2][PATCH 5/9] Memory managemnet - restore state Oren Laadan
2008-08-21 10:07 ` Louis Rilling
2008-08-21 3:06 ` [RFC v2][PATCH 6/9] Checkpoint/restart: initial documentation Oren Laadan
2008-08-21 3:06 ` [RFC v2][PATCH 7/9] Infrastructure for shared objects Oren Laadan
2008-08-21 10:40 ` Louis Rilling
2008-08-26 17:01 ` Dave Hansen
2008-08-27 8:26 ` Louis Rilling
2008-08-21 3:07 ` [RFC v2][PATCH 8/9] File descriprtors - dump state Oren Laadan
2008-08-21 11:06 ` Louis Rilling
2008-08-25 3:28 ` Oren Laadan
2008-08-25 10:30 ` Louis Rilling
2008-08-21 3:07 ` [RFC v2][PATCH 9/9] File descriprtors (restore) Oren Laadan
2008-08-21 5:26 ` Oren Laadan
2008-08-21 5:15 ` [RFC v2][PATCH 1/9] kernel based checkpoint-restart Oren Laadan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080821093529.GG581@hawkmoon.kerlabs.com \
--to=louis.rilling@kerlabs.com \
--cc=arnd@arndb.de \
--cc=containers@lists.linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=orenl@cs.columbia.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®