Re: [PATCH 7/7] binfmt: Introduce the binfmt_img exec handler

[Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>]

On 07/23/2011 02:46 AM, Matt Helsley wrote:
> On Thu, Jul 21, 2011 at 08:51:27AM +0200, Tejun Heo wrote:
>> On Fri, Jul 15, 2011 at 05:48:09PM +0400, Pavel Emelyanov wrote:
>>> When being execve-ed the handler reads registers, mappings and provided
>>> memory pages from image and just assigns this state on current task. This
>>> simple functionality can be used to restore a task, whose state whas read
>>> from e.g. /proc/<pid>/dump file before.
>>
>> Ummm... iff the process is single threaded. :(

Yup :( This is the weak side.

>> Much more complex machinery is needed to restore full process anyway
>> which would require some kernel facilities but definitely a lot more
> 
> Agreed,

Well, let me describe why I chose the binfmt handler for restore.

The basic idea is very simple - you have to create a process with a defined
values in registers and defined set of memory mappings (with the memory
contents). This creation is obviously done by some (maybe another) process.

Thus we have two ways to go - either we transform the restoring task into
the target one or we freeze the target one and repopulate it "remotely".

The 1st approach seemed to be more elegant to me, and with this one we do
already have an API for turning one VM+regs into another - the execve.

If you can suggest another way - I'm open for discussion.

>> logic in userland.  I really can't see much point in having
> 
> I disagree (surprise! ;)).
> 
>> dumper/restorer in kernel.  The simplistic dumper/restorer proposed
>> here isn't really useful - among other things, it's single threaded
>> only and there's no mechanism to freeze the task being dumped.  It is
> 
> To be fair Pavel used signals to stop/resume the task. It's not
> a good solution but it's a start (more below).
> 
>> almost trivially implementable from userland using existing
>> facilities.  I wonder what the point is.
> 
> No, I think that ultimately an addition to the cgroup freezer will
> be needed.

Sure it will be! I planned to use one in the next iterations and used
the sigstop just for simplicity.