Re: prctl(PR_SET_MM)

From: u3557@miso.sublimeip.com (Amnon Shiloh)
To: rostedt@goodmis.org (Steven Rostedt)
Cc: u3557@dialix.com.au, oleg@redhat.com (Oleg Nesterov),
	palves@redhat.com (Pedro Alves),
	dvlasenk@redhat.com (Denys Vlasenko),
	jan.kratochvil@redhat.com (Jan Kratochvil),
	gorcunov@openvz.org (Cyrill Gorcunov),
	xemul@parallels.com (Pavel Emelyanov),
	fweisbec@gmail.com (Frederic Weisbecker),
	mingo@redhat.com (Ingo Molnar),
	a.p.zijlstra@chello.nl (Peter Zijlstra),
	linux-kernel@vger.kernel.org
Subject: Re: prctl(PR_SET_MM)
Date: Tue, 19 Feb 2013 17:25:31 +1100 (EST)	[thread overview]
Message-ID: <20130219062531.4F317592076@miso.sublimeip.com> (raw)
In-Reply-To: <1361216963.23152.168.camel@gandalf.local.home>

Steven Rostedt wrote:

> If only you, or a few people are using it (ie. distros don't see a
> need), then it will be up to you to make the changes.

I believe that this functionality is of a general nature and is needed
by many, not only by myself and by the CRIU group, but by all user-level
software packages, past present and future, that provide some form or
another of reconstructing a Linux process.

For example:
1) Checkpoint-restore
   - the ability to resume a computation after computer crashes.
2) Process-migration
   - the ability to have a running computation change computers.
     (for numerous reasons, including planned shutdown; overheating;
     load-balancing; increased memory demands; the original computer
     being required by higher-priority users, etc. etc.)
3) Process-duplication
   - the ability to have a running computation continue in parallel from
     a point in time on two or more computers, so that if one of them
     fails, at least one copy will still be running (in time-critical
     missions, a periodic checkpointing may not be sufficient).

To reconstruct Linux process(es), one must be able to restore all their
memory contents, states and registers to their original and consistent
values.    

Other than the code currently enclosed in "CONFIG_CHECKPOINT_RESTORE",
nothing else in the kernel provides the ability to set those 11 fields:

     start_code, end_code, start_data, end_data, start_brk, brk,
     start_stack, arg_start, arg_end, env_start, env_end.

There are many possible ways to implement this functionality and if you
believe that it would be a good idea, I could instead send a simple,
independent kernel patch that sets those 11 fields.  It would be shorter
than the current and perhaps implemented as a new "ptrace" function,
but given that the CRIU group already wrote this code and that it is
already in the kernel, I am concerned that trying to duplicate it might
interfere with their work, so I first ask for the relevant code in
"kernel/sys.c" to no longer be enclosed by an #ifdef.  What do you think?

Best Regards,
Amnon.