Re: [patch 2/2] fs, proc: Introduce the /proc/<pid>/map_files/directory v6

[Tejun Heo]

Hello,

On Thu, Sep 01, 2011 at 04:13:54PM +0400, Pavel Emelyanov wrote:
> Because with the handler restore process looks very natural and simple - each
> task does the following steps
> 
> 1. restore task resources (open files, set IDs, restore connections, wire back timers, etc.)
> 2. call execve() to jump into new memory+registers context which is
>    a. unmap all the user memory
>    b. map required mappings
>    c. populate them with data
>    d. restore registers
>    e. restore IP

But what about multiple threads?  exec is already scary enough as it
is and I don't think it would be wise to overload it for this.

I don't really think binfmt handler would be able to achieve
completeness without ending up with full de-serializer in kernel.
There are a lot of states which already have API to manipulate from
the userland thread itself and they all will need to be replicated in
the binfmt handler.  It really has to be full de-serializer if it
wants to function like you described.

And if we're gonna have interventions anyway, I can't see much point
in implementing something which seems simpler - it's not gonna be
actually simpler.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/