All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Linux Containers <containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>
Subject: cryo and mm->arg_start
Date: Fri, 11 Jul 2008 08:13:45 -0500	[thread overview]
Message-ID: <20080711131345.GA18870@us.ibm.com> (raw)

What cryo does right now to restart some task (say openmp stream) is:

	1. fork, ptrace_tracem(), then execute the original application
	   (stream)
	2. (some other stuff)
	3. through ptrace, cause the restarted process to read the
	   checkpointed data back into writeable maps.  This includes
	   the stack

The restarted task's filename is correctly reported through
/proc/$$/cmdline.  Once we rewrite the stack, it is corrupted.

The reason is that the cmdline contents are taken from mm->arg_start,
which varies with each execution.

On the one hand it's kind of a "small thing."  But IIUC it's like
did_exec in that there is no way to fix it for userspace.

One thing we could do here is to start extending the cryo approach
with Eric's checkpoint-as-a-coredump (caac?).  We generate the
tiniest of coredumps which, at first, contains nothing but
mm->arg_start and maybe a process id.  It would be simplest if
it also contained a filename for the real executable, but I don't
know that we could get away with that.  If we *could* get away
with that, then we could have a trivial fs/binfmt_cr.c "execute"
such a caac file, which would mean it would exec the original
executable, then change process settings in accordance with the
ccac file contents.

Any other ideas?  Comments?

-serge

             reply	other threads:[~2008-07-11 13:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-11 13:13 Serge E. Hallyn [this message]
     [not found] ` <20080711131345.GA18870-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-07-11 16:38   ` cryo and mm->arg_start Dave Hansen
2008-07-11 21:26     ` Serge E. Hallyn
2008-07-11 22:01     ` Matt Helsley
     [not found]       ` <1215813673.5456.284.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2008-07-13 21:08         ` Serge E. Hallyn
     [not found]           ` <20080713210846.GD8186-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-07-15 21:40             ` sukadev-r/Jw6+rmf7HQT0dZR+AlfA
     [not found]               ` <20080715214050.GA29648-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-07-16 15:23                 ` Serge E. Hallyn

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=20080711131345.GA18870@us.ibm.com \
    --to=serue-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
    --cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.