From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Oren Laadan <orenl@cs.columbia.edu>
Cc: containers@lists.linux-foundation.org, jeremy@goop.org,
linux-kernel@vger.kernel.org, arnd@arndb.de
Subject: Re: [RFC v5][PATCH 5/8] Restore memory address space
Date: Mon, 15 Sep 2008 12:14:04 -0700 [thread overview]
Message-ID: <1221506044.16561.37.camel@nimitz> (raw)
In-Reply-To: <1221347167-9956-6-git-send-email-orenl@cs.columbia.edu>
On Sat, 2008-09-13 at 19:06 -0400, Oren Laadan wrote:
> +struct file *cr_read_open_fname(struct cr_ctx *ctx, int flags, int mode)
> +{
> + struct file *file;
> + char *fname;
> + int flen, ret;
> +
> + flen = PATH_MAX;
> + fname = kmalloc(flen, GFP_KERNEL);
> + if (!fname)
> + return ERR_PTR(-ENOMEM);
> +
> + ret = cr_read_fname(ctx, fname, flen);
> + cr_debug("fname '%s' flags %#x mode %#x\n", fname, flags, mode);
> + if (ret >= 0)
> + file = filp_open(fname, flags, mode);
> + else
> + file = ERR_PTR(ret);
> +
> + kfree(fname);
> + return file;
> +}
PATH_MAX is about as short of a global macro name as you're going to
get. It should just be used directly. Please kill 'flen'.
> +static int cr_read_pages_vaddrs(struct cr_ctx *ctx, unsigned long nr_pages)
> +{
> + struct cr_pgarr *pgarr;
> + unsigned long *vaddrp;
> + int nr, ret;
> +
> + while (nr_pages) {
> + pgarr = cr_pgarr_current(ctx);
> + if (!pgarr)
> + return -ENOMEM;
> + nr = cr_pgarr_nr_free(pgarr);
> + if (nr > nr_pages)
> + nr = nr_pages;
> + vaddrp = &pgarr->vaddrs[pgarr->nr_used];
> + ret = cr_kread(ctx, vaddrp, nr * sizeof(unsigned long));
> + if (ret < 0)
> + return ret;
> + pgarr->nr_used += nr;
> + nr_pages -= nr;
> + }
> + return 0;
> +}
> +
> +static int cr_page_read(struct cr_ctx *ctx, struct page *page, char *buf)
> +{
> + void *ptr;
> + int ret;
> +
> + ret = cr_kread(ctx, buf, PAGE_SIZE);
> + if (ret < 0)
> + return ret;
> +
> + ptr = kmap_atomic(page, KM_USER1);
> + memcpy(ptr, buf, PAGE_SIZE);
> + kunmap_atomic(page, KM_USER1);
> +
> + return 0;
> +}
> +
> +/**
> + * cr_read_pages_contents - read in data of pages in page-array chain
> + * @ctx - restart context
> + */
> +static int cr_read_pages_contents(struct cr_ctx *ctx)
> +{
> + struct mm_struct *mm = current->mm;
> + struct cr_pgarr *pgarr;
> + unsigned long *vaddrs;
> + char *buf;
> + int i, ret = 0;
> +
> + buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + down_read(&mm->mmap_sem);
> + list_for_each_entry_reverse(pgarr, &ctx->pgarr_list, list) {
> + vaddrs = pgarr->vaddrs;
> + for (i = 0; i < pgarr->nr_used; i++) {
> + struct page *page;
> +
> + ret = get_user_pages(current, mm, vaddrs[i],
> + 1, 1, 1, &page, NULL);
> + if (ret < 0)
> + goto out;
> +
> + ret = cr_page_read(ctx, page, buf);
> + page_cache_release(page);
> +
> + if (ret < 0)
> + goto out;
> + }
> + }
> +
> + out:
> + up_read(&mm->mmap_sem);
> + kfree(buf);
> + return 0;
> +}
> +
> +/**
> + * cr_read_private_vma_contents - restore contents of a VMA with private memory
> + * @ctx - restart context
> + *
> + * Reads a header that specifies how many pages will follow, then reads
> + * a list of virtual addresses into ctx->pgarr_list page-array chain,
> + * followed by the actual contents of the corresponding pages. Iterates
> + * these steps until reaching a header specifying "0" pages, which marks
> + * the end of the contents.
> + */
> +static int cr_read_private_vma_contents(struct cr_ctx *ctx)
> +{
> + struct cr_hdr_pgarr *hh;
> + unsigned long nr_pages;
> + int parent, ret = 0;
> +
> + while (!ret) {
> + hh = cr_hbuf_get(ctx, sizeof(*hh));
> + parent = cr_read_obj_type(ctx, hh, sizeof(*hh), CR_HDR_PGARR);
> + if (parent < 0)
> + return parent;
> + else if (parent != 0)
> + return -EINVAL;
> +
> + cr_debug("nr_pages %ld\n", (unsigned long) hh->nr_pages);
> +
> + nr_pages = hh->nr_pages;
> + cr_hbuf_put(ctx, sizeof(*hh));
> +
> + if (!nr_pages)
> + break;
> +
> + ret = cr_read_pages_vaddrs(ctx, nr_pages);
> + if (ret < 0)
> + break;
> + ret = cr_read_pages_contents(ctx);
> + if (ret < 0)
> + break;
> + cr_pgarr_reset_all(ctx);
> + }
> +
> + return ret;
> +}
That's an interesting loop condition, especially since it will never
actually get triggered. while(1) would give the same functionality,
right?
-- Dave
next prev parent reply other threads:[~2008-09-15 19:14 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-13 23:05 [RFC v5][PATCH 0/9] Kernel based checkpoint/restart Oren Laadan
2008-09-13 23:05 ` [RFC v5][PATCH 1/8] Create syscalls: sys_checkpoint, sys_restart Oren Laadan
2008-09-15 20:28 ` Serge E. Hallyn
2008-09-13 23:06 ` [RFC v5][PATCH 2/8] General infrastructure for checkpoint restart Oren Laadan
2008-09-15 17:54 ` Dave Hansen
2008-09-15 17:59 ` Dave Hansen
2008-09-15 18:00 ` Dave Hansen
2008-09-15 18:02 ` Dave Hansen
2008-09-15 18:52 ` Oren Laadan
2008-09-15 19:13 ` Dave Hansen
2008-09-16 12:27 ` Bastian Blank
2008-09-15 21:15 ` Serge E. Hallyn
2008-09-13 23:06 ` [RFC v5][PATCH 3/8] x86 support for checkpoint/restart Oren Laadan
2008-09-15 21:31 ` Serge E. Hallyn
2008-09-13 23:06 ` [RFC v5][PATCH 4/8] Dump memory address space Oren Laadan
2008-09-17 6:48 ` MinChan Kim
2008-09-13 23:06 ` [RFC v5][PATCH 5/8] Restore " Oren Laadan
2008-09-15 19:14 ` Dave Hansen [this message]
2008-09-13 23:06 ` [RFC v5][PATCH 6/8] Checkpoint/restart: initial documentation Oren Laadan
2008-09-15 20:26 ` Serge E. Hallyn
2008-09-17 6:23 ` MinChan Kim
2008-09-13 23:06 ` [RFC v5][PATCH 7/8] Infrastructure for shared objects Oren Laadan
2008-09-16 16:48 ` Dave Hansen
2008-09-17 7:31 ` MinChan Kim
2008-09-16 20:54 ` Serge E. Hallyn
2008-09-16 21:36 ` Oren Laadan
2008-09-16 22:09 ` Serge E. Hallyn
2008-09-13 23:06 ` [RFC v5][PATCH 8/8] Dump open file descriptors Oren Laadan
2008-09-14 9:51 ` Bastian Blank
2008-09-14 15:40 ` Oren Laadan
2008-09-16 23:03 ` Serge E. Hallyn
2008-09-22 15:31 ` Dave Hansen
2008-09-16 15:54 ` Dave Hansen
2008-09-16 16:55 ` Dave Hansen
2008-09-13 23:06 ` [RFC v5][PATCH 9/9] Restore open file descriprtors Oren Laadan
2008-09-16 23:08 ` Serge E. Hallyn
2008-09-17 0:11 ` Oren Laadan
2008-09-17 4:56 ` Serge E. Hallyn
2008-09-22 16:02 ` Dave Hansen
2008-09-13 23:22 ` Oren Laadan
2008-09-17 14:16 ` [RFC v5][PATCH 0/9] Kernel based checkpoint/restart Serge E. Hallyn
2008-10-08 9:59 ` Oren Laadan
2008-09-24 21:42 ` Serge E. Hallyn
2008-09-25 12:58 ` Cedric Le Goater
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=1221506044.16561.37.camel@nimitz \
--to=dave@linux.vnet.ibm.com \
--cc=arnd@arndb.de \
--cc=containers@lists.linux-foundation.org \
--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